I'm not actually averse to a programming environment where the only ground truth is the running image. I love that kind of environment! In my editor, where worst case I dump some state when I restart, and I can just not play such dangerous games when on call or there otherwise exists a risk of winning such stupid prizes. Production has rules. Or it had better.
That said, if you want me to go back to dynamic typing, there's a fee. The grass really is a lot greener over here.
Debugging can be extremely hard when there are multiple complex frameworks/libraries doing magic stuff, plus extensions by the current team.
In practice this is all very convenient when you're writing the code, but not so much when you have a production issue.
The best of the best developers may have the resolve necessary to ignore their emotions and stick to writing 'magic-less' code when they move past the one thing Rails does well, but most projects are going to land in the laps of most developers who aren't that. I am sure we can find counterexamples of where exceptionally skilled teams have been able to wrangle Rails, but the exceptions do not make the rule.
On the other hand, when beginning in a place where writing ugly, boring, but at the same time usable code is the norm, even the average developer tends to stick with it when they need to do things that are "off the Rails". They don't have the original enamourment to get caught up in. There are plenty of developers who can still manage to screw this up too, but, again, exceptions do not make the rule.
Rails is just a tool, of course. The outcome ultimately is down to the operator. But there is a certain psychology at play that introduces difficulty. It is kind of like giving the average daily commuter, who is a perfectly fine driver under normal circumstances, a supercar with features they can fall in love with. In theory it's just a car to drive as they normally do, but they're bound to do something stupid with it when the emotions take over.
1) Rails and Ruby will gladly let you make an absolute garbage fire out of your codebase, while it still technically works, and discovering how exactly the garbage fire is structured so you can start trying to put it out is unusually difficult in Rails. You don't have to make it a garbage fire, but they won't do a single thing to discourage it, and once it's bad, it's hard for an outsider to show up and figure out how to fix it, because of how the framework and language are designed.
2) Rails is often chosen by very price-sensitive companies trying to move fast, as cheaply as possible. This means high turnover, lots of enthusiastic juniors, outsourcing (often passing through multiple outsourced teams...) and often mediocre or poor management oversight.
The result is that a high proportion of Rails codebases in the wild are both remarkably terrible and impractically difficult to restore to some non-terrible state (i.e. they're the kind of cases where the right call really is to just start over—one of the things that makes them hard to work with is that a bad rails codebase is especially hard to rewrite-in-place, it's just a ground-up replacement job usually, but you won't actually be allowed to do that because see again: price sensitive, so you'll just live with an awful pace of development and poor application performance while management gets increasingly frustrated by the outcomes of their own choices)
I do wonder if Rails is so bad compared to other frameworks that it deserves such a distinct treatment.
Over the decades I’ve worked with at least half a dozen popular frameworks that fit this description, is the same for you or is Rails truly unique in this regard?