That doesn't mean you can't do interesting things with it, but rather that you are essentially talking about an application closely tied to the db schema it stores its data in. The idea of enterprise-class applications sharing their data in a common database is something entirely foreign to (and incompatible with) the Rails way.
This doesn't mean it can't be used in an enterprise environment. For example, you could have a Rails/MySQL app with data imported periodically into a PostgreSQL multi-application database, but I wouldn't call the former "enterprise-class."
They're swapping Java for Ruby, not Java for Rails.
Ruby is, performance aside, a really nice language. It's certainly possible to build something "enterprise class" in Ruby. Especially as soon as you start treating Ruby as a meta-language and build your own DSLs in it
Rails on the other hand isn't really enterprise grade. It's constrained by Active Record, and the immaturity (and lack of popularity) of the alternatives.
That's all part of the architectural choice: if you're building a toy, then you don't to build it with an industrial class framework.
I've had the experience in reverse: working on a system built on a toy framework which started to fall to pieces the second it became obvious* that it required industrial level tooling. In that case it lead to irreplaceable data loss.
* It was obvious to me from the start that an Enterprise-level framework was required. I got the hint from the 30-page auditing requirements specification.