Comment by jfinnery

After a lot of consideration of this question (I have also all-but written off Rails work, after doing a lot of it) I think it's a combination of two things, one technical, one business-social:

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)