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.
But I do see the fading popularity of Rails (and therefore) Ruby to start affecting its usefulness. Less libraries, fewer bindings, abandoned libs and fewer hosting options.
And that there, is the whole "Problem" of Ruby.
Ruby is a beauty. Rails isn't. It's nice, productive (for certain niches) and has a long track-record. But Rails is also often the root of problems such as maintainability, long-term-productiveness, hosting (performance, scaling), and lock-in.
There are far better solutions for simple CRUD-apps today than writing them all out in MVC code. And when you need complex business-logic (i.e no longer a simlpe CRUD app) the , the weird MVC (plus Concerns) that rails offers is simply not cutting it.
Yet Ruby is Rails, and Rails is Ruby. So when Rails looses its niche and usefulness, Ruby uses it's niche and usefulness. And that's a shame.
(I am a 12+years Ruby, former Rails, and now moving-to-Rust developer)