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).