No doubt Go's stdlib is useful, and there's plenty of things it got right. However, it's not immune to making some mistakes and having to freeze them forever. The more functionality you add, the harder it gets to get it perfect on the first (and only) try. Search for "deprecated site:https://golang.org/pkg/" finds various issues ranging from cosmetic mistakes to entire packages being deprecated.
CompressedSize uint32 // Deprecated: Use CompressedSize64 instead.
CompressedSize64 uint64 // Go 1.1
// Deprecated: HeaderMap exists for historical compatibility
// and should not be used.
Requirements may change over time, so even getting something perfect now is not a guarantee it will last (e.g. pre-UTF-8 languages froze byte-oriented or UCS-2 strings, even though these were good decisions at the time).
Sometimes improvements are not worth the cost of deprecation and replacement, so things are just left as they are. For example, an HTTP interface designed for request-response HTTP/1 works for stream-oriented HTTP/2, but support for push, prioritization and custom frames is bolted on. Packet-oriented HTTP/3 will add even more stuff that will have to be retrofitted somehow to the old model. Libraries can come and go, but std can't just throw away an old interface and start over.
Sometimes improvements are not worth the cost of deprecation and replacement, so things are just left as they are. For example, an HTTP interface designed for request-response HTTP/1 works for stream-oriented HTTP/2, but support for push, prioritization and custom frames is bolted on. Packet-oriented HTTP/3 will add even more stuff that will have to be retrofitted somehow to the old model. Libraries can come and go, but std can't just throw away an old interface and start over.