This will likely be controversial, but IMO both frameworks will "go wrong by default" if your codebase/feature set/team working on it start to get large, and rails is worse. There is no real modularity of features or services encouraged, you by default just have a big bag of models with all sorts of implicit couplings because they're all hooking into each other's public ORM methods and lifecycle hooks and it becomes a nightmare.

By using lighter weight frameworks you're forced to build parts of your own framework in some ways, which can be a bit more work in the short term, but that means it can be optimized for your domain and you can do more to set up explicit boundaries/document how the team should use things. You can also do this in rails/Django, but then you start ignoring the built-in stuff that made them popular in the first place, and there is such a strong idea of "the rails way" that it'll be hard to get buy-in to diverging from that.

OTOH if you're building something that has a pretty moderate scope and aren't worried about it getting too big, both will get the job done fine.

As additional points, rails is also quite a bit slower, and python is honestly a more versatile language than ruby these days (if you want to pull in any ML or scipy code there are obviously a lot more python options).

> There is no real modularity of features or services encouraged...

I've used multiple apps per Django project for grouping and isolating features. The Two Scoops book lays out a nice project architecture for doing this, and some people take it as far as to deploy separate Django apps within the same project as separate services.

Yeah it's certainly possible, in both Django and Rails. But I'd still argue that both frameworks lead you astray by default unless you consciously go against the grain to avoid it.