There's a major flaw in the R/R culture: they have no interest in maintaining stable APIs. If you want to upgrade your Rails app to the latest version of some library, you might as well do a rewrite of your entire app. So many of the APIs change from release to release that most of your gems will stop working unless you upgrade. When you upgrade the gems, your code will stop working, because most of the gems will have changed their public API. If you've got a non-trivial application, you will essentially be unable to upgrade. You will stop getting security updates. What minor upgrades you can manage to do will leave things partially broken, and you'll just get used to it being broken. (for example, one project I've worked on is stuck with a brain-damaged RSpec library that reports error messages without interpolating the strings, you always get "Expected CONDITION, got FAILURE, see CODE" in the logs)
My recommendation: only use Rails for short term projects that will be completely shut down after a few months.
I know that it's common wisdom that "no ruby engineer will ever want to switch to java", but that's because you've never been saddled with a 2-year-old rails project (or a 5-year-old plain-ruby project, which will have the same symptoms, just more slowly). Then your team will be begging for something that runs its test suite quickly, that has enough static analysis to know if you're using an outdated API, that has a decent metrics library, where you can query the state of the VM, that doesn't constantly leak memory, that plays nicely with databases that have real constraints, that has fewer race conditions in common libraries, etc etc etc.