When I add a foreign package to my third-party tree in a C program, I know every time I build the system exactly what version of the code I'm getting. On larger, longer-term projects I've worked on, we've gone through pretty elaborate effort not only to package the third-party code along with our own, but also to carefully manage what versions we're using while hiding that detail from the actual program (so that, for instance, version numbers don't infect the #include directives in the source code). Golang's package system does a good job of streamlining this process, so that as long as you don't try to use it like Rubygems, you can create a reliable build environment for an important program with little effort.
Idiomatic bundler, on the other hand --- and, just take my word for it that we've seen a lot of different teams Gemfiles --- treats something like "haml" or "eventmachine" as something akin to a system dependency; versions, when specified, are often fuzzy, like "anything from 1.1.0 to 1.1.9 is acceptable". Ultra-specific versioning in Gemfiles is brittle; a "bundle install" on a mostly-rigid Gemfile can be expected to routinely fail as one gem's dependency on another fails a constraint in the file.
There's an upside to the Bundler mechanism, which is that it's very easy to use and doesn't require you to think about the actual code. In fact, Rubygems even hides cross-language dependencies, so that you can easily use libraries that happen to be native C code without even having to know that you're bridging. But there's a downside too, which is that it's opaque and, like I said, brittle.
Basically you have to decide whether tracking your upstreams is more important than having a deterministic build. The C programmer in me is obsessed with deterministic builds, and Golang appeals to the C programmer in me, not the Ruby programmer.
Again, it's totally legitimate to complain that there isn't a widely-supported npm-alike for Golang. I don't necessarily want one of those, but I can see how a competent programmer would! I'm just saying that it's not reasonable to compare "go get" to npm; they aren't systems with the same goals, even though they sort of look like they are.