I think the animosity towards "over use" by some of the core community is misguided. The continued work that goes towards improving extensibility and features is surely a sign that someone finds it worth contributing towards. And the number of projects on Github or Django Packages that hook into the admin have to be written by somebody.
I think the right comparison here is to Flask-Admin, though, not Flask itself, and I’ll just say that the app I have to deal with that’s built on Flask-Admin is a nightmare, certainly no better than an equivalent app using Django Admin would be.
Re the Django ORM, SQLAlchemy is certainly better in many ways, but the Django ORM is pretty good these days (and has been for a while IMO).
If I know I’ll have complex database requirements that Django can’t easily handle, I’d much rather use Pyramid + SQLAlchemy than Flask.
It really is not.
IME, this stack has been pretty simple both at-scale and at-home. At scale, my experience is mostly using it in REST APIs serving a react frontend.
At-home, I've used it to setup numerous graphql services (with the graphene plugin).
Admittedly, there's probably 100 different ways to configure anything wrong, especially for any framework written in Python. But once you witness a "golden path", and stick to it, it's pretty straightforward. (The Flask docs have improved a lot in this regard, in the last few years)
Also, there’s nothing about these apps that requires the alleged flexibility of Flask, so there’s a lot of issues with dependencies and integrating extensions. That’s a lot of extra work and probably weakens security for no benefit at all.
Upgrading a big Django app is much simpler IME.
These things are difficult both to depend upon externally and to maintain, due to the dependency/upgrade issue you mentioned.
For an example in a similar ecosystem: at a previous company, at one time we used SQLalchemy-continuum for audit tables. We found some bugs and were not able to upstream them. When we wanted to upgrade SLQLAlchemy to X.Y, we were stuck with this dependency that required SQLAlchemy X.Y-1.
After a few years, we realized it was cheaper to cook up a SQLAlchemy-Continuum subset that met our needs, so it'd be easier to keep in line with SQLAlchemy.
It's a very different mindset from Django; I think there's an appropriate context for each.
I personally wouldn't want my web framework to implement login/password/email-reset for me, although I understand Django offers it to varying degrees. It's a space where "best practice" has evolved dramatically in the past decade.
[1]: https://flask-oidc.readthedocs.io/en/latest/ they looked a lot like this, fwiw. Although to your point, this too, hasn't been updated in 5 years. :)
The main point though is that I'm not interested in being on the forefront of login, it is not a differentiator (unless project is a laggard). In fact being five years behind bleeding-edge sounds a bit perfect.