Or put differently, why does the author think that "everyone knows it's silly" to have different libraries doing the same thing in different ways?
I think a valuable discussion that could come from this is to seek to understand why it’s “de facto” standard library instead of “de jure” standard library.
I’ve heard it said that “the standard library is where popular packages go to die”, and I think that’s very true. I’m very happy that Requests isn’t part of the standard library, because that means that updates - including updates that are extremely important to maintaining the health of the library over time - are possible without an entirely separate release of cPython itself.
"But that would require us to port to a different http library - do you have any idea how many places we do intricate things with requests all over the place?"
vs.
"Ok, let's test it out switching requests to its async mode..."
Async is a whole different paradigm. You can't just "turn it on" in a library without significantly affecting how one interfaces with it.
I'd be very careful with the word always there. I've worked in projects where almost every external library we used someone felt they had to build a "wrapper" class or two around. When you're doing that you realize the reality of the situation is that most developers are totally shit at designing APIs, and instead of using the library's probably-quite-well-thought-out & flexible API (after all, that's likely why it became popular enough to come to your attention), you've got to spend your life using this - for lack of a better term - gimped up abortion of an interface. Which typically doesn't even succeed in the purported task of giving you library independence so long as it doesn't sanitize all of its possible return values and catch & re-throw custom exceptions. Be wary of this hole.
But yes, I did try and specifically mention intricate use of requests to try and leapfrog that conclusion.