This is not an example that works too well for you because it's exactly my point. The vast majority of users use hashlib, even in circumstances where they should be using something better. For example, most web frameworks in Python use PBKDF2-based password hashing because that's what hashlib has, even though scrypt or Argon2 would be better choices.
The standard library acts as a dragging force in this way.
Go is a great example here, because it has a large and very good standard library. However, the reason for this is just straightforwardly the result of investment. Go's core standard library has been heavily invested in, and as a result has a lot of great quality implementations in it.
However, I am profoundly uncomfortable with assuming that that investment will continue if we keep adding things to the Swift standard library. Each extra thing in the stdlib is a requirement for extra ongoing maintenance investment, and if that investment is not made then there are ongoing harms associated it. Building up a wider ecosystem of third-party packages distributes that risk, and makes it easier to supplement.
I don't understand your argument here. My understanding of your argument is that, by and large, third-party packages are of low quality and under maintained, and that is unacceptable for production services. Given that you're arguing in favour of putting things in the standard library, my assumption (and it is only an assumption, please correct it if it's wrong) is that you believe the things in a language standard library are of high quality and maintained.
But I don't think the second case follows from the first. If there is someone who can maintain a stdlib quality implementation, why can't they do that outside the stdlib? What is magic about the standard library that does not apply to third party packages?
I think this is the fundamental source of our disagreement: I don't think the standard library has any special status in terms of being well maintained or high quality by virtue of being the standard library. In the case of what the Swift standard library currently covers, I believe it is both well-maintained and high quality. But there's no guarantee of that continuing.
I think this is the fundamental source of our disagreement. But I want to hit on something for a moment, because it's key. We both believe that the Swift standard library is good software right now. Your response to that appears to be to want to make the standard library cover more things, because that will mean more things have good quality implementations.
I have the opposite belief. I believe writing good software is hard, and the fact that software is in a standard library doesn't make it good. My belief is that the bigger we make the standard library, the more we dilute the focus of the standard library teams and run the risk of adding something bad, and once we add something bad it is very hard to undo that mistake. In a world of stable ABIs this is even harder, as you can only ever roll the ABI forwards, not backwards.
Your view is inherently optimistic: mine is inherently pessimistic.
I think the comparison is unfair, and represents a cherry-picked example, and here's why: no-one has proposed gzip for the Swift standard library.
Until someone does that, we're arguing in the world of highly abstract counterfactuals. It's like me pointing out that Go has a first-class X509 library and Swift doesn't, as well as not having any great third-party X509 libraries. Which of those situations is better? Clearly Go's, as having one good library is better than having zero good libraries.
But let me provide a much better example: asynchronous I/O. Python has asynchronous I/O in its standard library, in the form of asyncio and outside it, with a wide range of implementations from Twisted to Trio. Swift has asynchronous I/O outside its standard library in the form of SwiftNIO. Java has both, with NIO and Netty. Which situation would you prefer?
I choose this example deliberately because in my view there is no clear answer. SwiftNIO is not unsupported or fly-by-night. It does not attract less contribution or attention because it's outside the standard library. I would strongly contest the idea that it would be any better than it currently is by being in the standard library: in fact, I'll make the case that it has grown and improved much more quickly by being outside the standard library than inside it.
I don't think this situation is black and white. There are times when things should go into the standard library. But I think the assumption that things are better inside the stdlib than outside is not universally valid.