That's a fallacy in the first place (at least for web apps)... Most web application code spends most of its time waiting for the db to respond, not number-crunching.
Out of curiosity, what were you doing that made your SBCL numbers so high? I've got 1.8.6 (running natively on OSX) clocked at 1.3 seconds and SBCL (linux on VMWare) at 78 ms.
(These times are with the random number generation removed, with them the SBCL time jumps to 90ms and 1.8.6 jumps to 4 seconds).
=============
Wszystkie testy były wykonywane na MacBook Pro Core2 Duo 2.16GHZ, 4GB RAM i systemie Mac OS X 10.5.4 Leopard + zainstalowana Java 1.6.0_05.
==================
those Jruby and jython numbers look pretty funny, tho. Being strictly a MRI and Cpython user, i dunno if Jruby and jython are/could hit both cores.
It is impressive though, that to beat the given Ruby time on my machine in SBCL, I actually had to add optimize declarations. Of course, I have no idea what kind of machine the published number were from, and I'm too lazy to try and install Ruby 1.9 myself, but it seems that the old 'Ruby use -> slowness' implication no longer holds.
[edit] Hold on, the Ruby 1.8 test, which takes 22 seconds in their figures, takes 4.3 on my machine. So that would mean Ruby 1.9 is like super-sonic ultra fast. At least on this benchmark. Which is mostly testing the speed of the sorting routine which I suppose is written in C. So what are we talking about, anyway? I'll shut up now.