Those who trade for buried complexity are doomed to start digging whenever they discover an edge case.
Maybe they never need to do that, in which case that's a bargain. But I tend to think that any old enough codebase continually accrues edge cases that must be solved.
I've never seen a ten year old Rails application, but from the Rails applications I have seen, I'm horrified by the thought of how it would look after that long.
I've been in a company that let their Rails applications grow for 7 years. Believe me, the oldest code was not pretty to read and almost impossible to refactor. When we finally had a real frontend team, the only way out was to reimplement the apps with a new architecture.
At one point I realized, I should not stick into one language and one framework. Ruby is good to know, but I'm better if I can also tackle Scala, Java, Rust, OCaml, Haskell, Python and so on. Also happier, I'd say... I can now choose the best tool for the job.
I've been there, done that--was part of a team that owned a java application that grew over a decade (and eventually ran the team). A year or so after I left, they retired the application.
Why? Because we owned all the complexity and couldn't support it.
Maybe that was my failing. Maybe the team's failing. But I don't think that having control of how the whole codebase fits together means you necessarily have more control over complexity.