Well... Ruby developers almost invariably do use gem in production. And of course, gems are not signed.

I suspect a lot of people will (as they do with gems or pips), given the extra trouble forking all your dependencies and keeping track of updates to them causes. Many companies don't have a team to take care of this process, just developers, and the easy route with bundler or with go get is to use the 3rd party code directly, though with bundler you can pin to a major/minor version at least. I'm not even sure there is much to gain security-wise by forking a gem/pkg/pip, save perhaps delays in your process that might save you from deploying an exploit before it is used, unless you have someone do a code audit on all the code. That's practical in a large org but not in many small shops.

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.

At the risk of some controversy, I think that if Go's core developers are serious about encouraging good software engineering, they should drop "go get" (presumably in Go 2). It seems to me that subrepositories / submodules at the version control level, with support for pinning, are the best way to manage dependencies.