Looking at the graphs: would I trade 2x gain in eventual performance for a 20x gain in startup speed, 3x leaner RAM consumption and great immediate performance? I wasn't sure, but after 2 months with JRuby - yes I would.
My vote goes to Ruby 1.9.4 coupled with speedy and efficient C extensions.
The way I see it, languages like Ruby aren't meant for high performance computing: one can pick from a dozen statically typed languages to implement time-critical algorithms. The power and beauty of Ruby is its flexibility, "fluidity", and ability to glue services provided by an operating system and a million OS-native modules. Just look into your /usr/lib.
JRuby lacks that: it only "glues" JARs together and it introduces a shockingly huge startup lag which makes your development feel like you're compiling C++ code between test runs. And even gluing JARs is kind of pointless: Java itself, with its plethora of autocompleting IDEs, is a much better environment to learn and experiment with APIs like Batik or Apache POI.
Perhaps JRuby simply isn't for you. We're using JRuby with Rails, and the tradeoffs are well worth it. Performance is quite good, and the laggy startup is irrelevant to a long-running server process like Rails.
More critically, our development time is significantly reduced by using a highly expressive language like Ruby. Code is more readable, more understandable, and a heck of a lot faster to write. Plus, we can still use all the neat Java libraries like Jetty, Lucene, and JavaMail. Add in things like java NIO, and it matches our needs nicely.
While JRuby might not suit your particular application, it's doing wonderful, useful work for a lot of people. Horses for courses, as they say.
Ruby may not be the fastest language in the world, but that doesn't mean that we shouldn't strive for better performance. As far as startup times are concerned, have you tried using nailgun?
One exception would be in multi-threaded applications. JRuby is the best choice in this domain from my experience. Ruby 1.9 still uses a GIL making JRuby a better choice for concurrent software.
One additional advantage is JRuby's ability to use structures like Clojure's concurrency primitives. AFAIK, there's nothing even close in the world of MRI and YARV.
JRuby's startup speed isn't that much different if you're actually running something fairly heavy, like a web framework; it's not like Rails starts up in 200ms on MRI and 4000ms on JRuby, both have you waiting for a few seconds. With source reloading they're not that different in practice.
Sure, leaner RAM consumption is nice, but so is stable RAM consumption. It's not uncommon to see a Rails app on MRI eventually grow from, say, 70MB to 300MB+ and never shrink thanks to heap fragmentation and gc confusion, while JRuby stabilizes at maybe 100MB.
Sure, I also have MRI services which sit stable at 8-15MB for 6 months or more and JRuby's not exactly going to help there, and for short running interactive tasks it's certainly not going to be my first choice, but having the choice is very, very good.
My vote goes to Ruby 1.9.4 coupled with speedy and efficient C extensions.