Because there's always something different that needs to be done for them once your project starts becoming non-trivial. You might need a different version of a gem (e.g. pure-java Nokogiri), or they're behind recent MRI features. And if you care about concurrency, it's different everywhere.
In my personal experience I've found MRI to be the best experience simply because that's what most other people are using, and there's a lot to be gained from being in the mainstream.
Don't get me wrong- I would actually love for JRuby to become the de-facto Ruby implementation. So many headaches are caused by native code in gems. And we'd have a solid foundation for GC, concurrency, etc. But that's not the current reality.
Rubinius does not need Gem replacements like you need in JRuby, it still has a compatible CAPI.
> [...] or they're behind recent MRI features.
Part of this is due to MRI having literally no specification process at all. Python has the PEP system, no such thing exists in Ruby land. People tried to change this in the past (http://rubyspec.org/design/) but with little to no success so far. As a direct result of this there are only two ways to keep up to date with what changes in Ruby:
1. Follow every issue reported on bugs.ruby-lang.org, forever.
2. Wait until users report issues about something not being present, behaving differently, etc.
> And if you care about concurrency, it's different everywhere.
This is FUD. An implementation may offer different primitives for concurrency (e.g. Rubinius has Rubinius::Channel) but they also offer shared APIs. For example, the Thread class works across all implementations as you'd expect. Whether you use this on JRuby or Rubinius the end result is the same: proper concurrency.
For me it's always the triple-whammy of being a bit (or a lot) slower, needing vastly more memory, and having astronomical startup times. Not exactly an appealing combination.
If you're seeing a situation where you need vastly more memory with JRuby, please file it. While there is a higher base memory footprint due to the JVM being booted, I've found in practice it's much better on RAM than MRI. We saved a lot of money on EC2 by switching to JRuby because servicing a new request with a thread was a lot cheaper than forking a process running Rails.
In my personal experience I've found MRI to be the best experience simply because that's what most other people are using, and there's a lot to be gained from being in the mainstream.
Don't get me wrong- I would actually love for JRuby to become the de-facto Ruby implementation. So many headaches are caused by native code in gems. And we'd have a solid foundation for GC, concurrency, etc. But that's not the current reality.