I guess I agree with you, that from some kind of evolutionary perspective, having yet another language-specific package and dependency management system, this time for Go, might be a good way to boost popularity / uptake of Go. The system doesn't necessarily need to be a good idea, just quick and easy to use.
On the other hand, I think that dependency management isn't really a language specific problem, and it is silly to have different incompatible language-specific solutions for it.
E.g. I work mainly with Python, that has popular python-specific packaging tools, yet those tools cannot express dependencies of python libraries upon e.g. native libraries. The python-specific tools are convenient on a pure-python project, for multi-language projects it feels more like an anti-pattern than a solution, particularly if you end up having to use many different packaging ecosystems / tools.
I think google's approach makes more sense in the context of an organisation where some kind of uniform approach can be imposed, and particularly where there are uniform approaches to code quality / test coverage / continuous integration.
To be clear -- I have never worked at google, this is my external perception.
I have worked somewhere where there are simultaneous software projects with wildly varying levels of code quality / test coverage / continuous integration, this does not seem to agree with very well with the source-control-based "import from HEAD" in one big repository. The organisation is currently transitioning from this approach to more decentralised many-repository approach linked with language specific package management. I do not think this change is a clear improvement, but it does make some things easier.
