Maybe referring to go packages having no metadata and being unsigned, so if a github account was hacked and you used go get on a third party pkg you could end up compiling unexpected exploit code into your binary?
I don't think Go is especially vulnerable in this regard, as you noted below ruby gems are also mostly unsigned just now, however I think there was a move to have those signed after the recent problems, and Go's pkgs don't have metadata or a facility to do this AFAIK. So that could be seen as a weakness (though one shared by many other package management systems).
I agree there's very little security difference anyway though between go get and bundle install for gems say (don't agree with the OP there), but go get has no clear way to add metadata like out-of-band code signatures as gems or pips do.
If the designers want to really take it to the next level, they should introduce, possibly with idiomatic behavior but preferable with syntax, the idea of version pinning or at least version hinting within the "import" syntax.
When your world enforces the assumption that the latest version of a dependency is stable and compatible, 'go get' is a perfectly reasonable solution.
That's how 'go get' works.
You get the dependency at a version control level, at a known-good version (because you pulled from the master branch) at the time you pulled, and after that it's up to you to update it.