This is really a matter (or problem) of how people use Rails. I am very much not a fan of magic, and I prefer explicit over implicit.

You cannot use the same approaches for serious, big Rails projects as you might for quick and dirty proof of concepts. And by that I mean OO, mixins, fat models, overemphasis of ORM, etc. will hurt down the road. But most of these same points are true for Django too.

The better way to use Rails is for the core features, and then keep the business logic in modules in "services" (just domain specific organized modules which have little or no dependency on Rails, and are therefore super easy to write complete tests for).

An organically grown Rails project that started as an MVP will predictably turn into a ball of sadness if not refactored significantly at various stages in the life of the project.

Last time I used Rails was years ago, but I found Rails had a huge mental load when developing. So much magic and inference, you had to carry the whole Rails mental model around with you to read some simple code. I think that's a danger in any framework, but it felt especially acute to me in Rails.

That's your experience, many think it was a fresh air using Rails than using Java for webdev.