Yes, this, and mostly this. I don't know exactly where this comes from, but then again I haven't been a professional for that long. Maybe it's because so much of Ruby web development is centered around Rails that someone just assumes that every new thing should just go into their existing Rails app as another model, another controller, another view, etc., instead of considering whether or not a whole domain of code could belong in another codebase or at least another process besides the same one being used by the Rails server. All the TDD in the world isn't going to prevent someone from making a bunch of poor choices around engineering or design patterns. Caching strategies can help, but they can also become crutches. At worst, they end up causing a lot of confusion when something isn't getting "updated", and some developer used a bunch of fragment caches triggered by different things.

In my experience, it's much easier to forego TDD, only write important tests, and try to divide things out into separate projects where it makes sense. That way bugs can be quickly squashed and new features can be added quickly(very little time wasted learning a bunch of complex mechanisms), unique components of a larger system can be updated & rolled back pretty independently, and you get more value out of your testing than most tests I've seen in Rails monoliths(often foolishly testing Rails features themselves). This can be done through gems or even completely separate Rails/Node/whateva applications/APIs that communicate(remember, sockets are pretty fast). If you must have a monolith, at least consider what things should be "first class" and whether or not you can afford to have things get processed in the background. Async is easy these days.

I love what Rails has done for me and what it represents, but I've become disenchanted by the lack of deep thought that it's fostered in new developers, which includes me where I was not that long ago.

This is something I think Django got much more right than Rails - it encourages splitting up of "sites" into smaller "apps", where an app is a bundled set of model/view/controller/routing and maybe a few other things. We exercise this design pattern a lot on the project I work on (we have ~350 apps in our monolith) and it's mostly a very nice codebase to work on.

I think microservices become far less necessary when the monolith is structured in this way. I'd rather have a clean API to a subsystem exposed as a Python function call than as an HTTP endpoint with all the reliability and distributed systems issues that come along with that.

This is also called "package by feature, not layer" in Java.

That is going to be an issue with any project with many developers that uses a popular framework irregardless of the language. It is very difficult to keep quality code hygiene with that many people touching a project. The key is compartmentalization: multiple applications, libraries, etc.