You mention this as a case against using Python, but this is entirely unrelated to Python as a framework. In other words, had they used PHP or Node or %s, they'd still have to face the issue of optimizing the request-to-response path.
This relates much more to the issues that often come with the common practice of separating your webserver, from your business logic (Flask, in our case).
> "so you have to use some asynchronous tooling"
Solutions such as mod_cgi and wsgi have been the standard for years at this point. That's, in many ways, a solved problem.
> "In order to get off the ground, you also need to use pip, which causes an inordinate number of problems vs. the bsd ports tree or .deb files."
Any specific issues you can expand on? Because this is a rather vague form of criticism.
Using pip is ridiculously easy. I've been using Python extensively in various production environments and rarely had to point a finger at pip. Package and dependency management in Python are solid (that isn't to say things can't improve).
> "You can use virtual environments for each script, but then patching zero days becomes infeasible."
Again, this is an entirely subjective form of criticism. I haven't had any issues with keeping my virtualenvs up to date.
> "If you want basic type safety, you need to rely on external tooling."
Again, you just seem to favor strongly typed languages and that's fine, but that's hardly a point against using Python here. Type safety is simply not a Python thing, much like weak typing is not a C thing.
> "In my experience, third party python libraries evolve types and api’s without warning. This shows up at runtime, so it introduces security holes."
Developers will sometimes break APIs. How is this a Python-specific issue? These things are literally happening everywhere.