Django while opinionated is very flexible too. unlike Rails.
that means you can mold it to fit your use case easily - don't like the ORM - you can plug SQLalchemy and use a different 'architecture'. + you can use multiple different databases if you think that's the right path. in Django there's no 'the rails way' - you choose your own path.
Django-admin by itself saves so much work specially If you're doing B2B stuff & you gotta onboard users.
I guess Django is not the best thing, but not the worst thing either. so a perfect middle ground.
Rails is flexible too. Everything that you mentioned here can also have the sample flexibility in Rails: You can use Arel and skip AR, you can use Plex instead of HTML and so on.
The Rails Way is a response to people changing too much Rails and making it super custom.
In the last 4 years alone I touched codebases ranging from Rails Way to Rails and everything dry.rb, to Rails and Grape and Sorbet, to Rails and service objects everywhere and a lot more combinations.
also Rails largely sits in a world where most apps are CRUD based or everything is CRUD e.g [0] - which for that purpose Rails has nice ergonomics.
whereas Django though it also provides almost similar abstractions in terms of CRUD - it doesn't assume your app will only do CRUD stuff - hence the flexibility e.g there's many apps where you only have a handful of endpoints that are user accessible maybe at most 15, then of course management of users via Django-admin but everything else is non CRUD e.g calling other systems
[0]: https://jeromedalbert.com/how-dhh-organizes-his-rails-contro...