"The only place I can imagine Go-based software being useful, is for code you've built yourself, for use in a always rolling forward cloud-environment you maintain yourself, where updating dependencies and rebuilding is part of the day to day operations."
Which is, you will notice, the core of where Go comes from.
Also, you may notice that "server" software is generally moving in this direction very quickly. "Containers" are basically static linking writ large. We're still early in the curve on this but I expect in the next few years we're going to see more people start pointing out that dynamic linking is basically obsolete nowadays (the first few brave souls have already started mumbling it), and even the only putative reason that people keep citing for it being a good idea, the ability to deploy security updates (but not ones that require ABI changes), is fading fast and was less important than people made it out to be anyhow. First, lots of people still basically don't do those updates. Second, even if you deploy the updates you still have to take the service down to restart it. Third, by the time you've instantiated the architecture that lets you manage your dynamic library updates at scale you've also instantiated the architecture you will need to simply rebuild your static-everything containers and redeploy them.
In another ten years I expect it to be simply common knowledge that if you can't completely rebuild and redeploy everything easily for a fix, you're not really operating at a professional level.