But difficulty aside, my point was Go waited until there were multiple established 3rd party package management tools for Go already in widespread use before even releasing their own experimental implementation.
Their inaction caused far more disruption to the ecosystem because people got fed up of waiting, implemented their own, integrated it into their workflow and then had to reintegrate a whole new system all over again a year or two later.
Your point about Googles needs is the one often cited for Gos inaction. But I think that actually makes the situation worse. Because if the Go team cannot empathise with use cases outside of one bespoke enterprise, then it really shouldn’t be released as a general purpose language available for all to use.
And I say this as someone who generally likes the language.
Especially since "Go team cannot empathise with use cases outside of one bespoke enterprise" — it shows self-awareness of their shorcomings. I think it's wise to let the target audience explore the design space themselves a bit first. Considerably lowers the risk of cementing the wrong design.
I do somewhat remember the drama around this at the time, but I my impression was that of a petulent community of various dependency management projects with too much ego attached to them to see the bigger, long-term picture.
You left out the part that explains why.