Although Rails code can be straightforward if you stick to the conventions, many real-world apps call for something more than that. So in practice, it's usually necessary to perform at least some level of metaprogramming, or at least some more exotic configuration.
Also, if you're using Rails library, you'll notice the hipster aspect of the Ruby/Rails community, which is to say many libraries are active for 1 or 2 years before the developer gets bored and someone else comes up with a hotter alternative. That's cool, it's quick evolution, but it also means real-world Rails developers have to spend a fair amount of time dealing with libraries that are either no longer maintained or are not yet mature.
I've built many real world applications. Very complicated ones and not just your average CRUD apps. I never had to do exotic configurations or metaprogramming craziness.
If a popular gem is replaced, I see many times, that the API of the gem, mimicks the old one, or detailed migration tutorials will be delivered. So a new gem is often similar to a major version bump.
I don't know if labeling rapid evolution as "hipster" is quite fair, but the underlying point is true. Have you gone back to a update a Rails project that is 3 years old or more? I have, and it's significantly more hassle in general than going back and updating a PHP project that is 10 years old.
Personally I think this is a small price to pay for a framework that stays up to date and still releases forward-thinking features on a regular basis (Rails modularization in 3.0 and the asset pipeline in 3.1 are amazing features that an emphasis on backwards compatibility could have made more difficult), but let's acknowledge that it is not an unmitigated win in all aspects.
Also, if you're using Rails library, you'll notice the hipster aspect of the Ruby/Rails community, which is to say many libraries are active for 1 or 2 years before the developer gets bored and someone else comes up with a hotter alternative. That's cool, it's quick evolution, but it also means real-world Rails developers have to spend a fair amount of time dealing with libraries that are either no longer maintained or are not yet mature.