Why does any of that truly matter? What matters most is if it meets the needs of people using the product, not what language it is written in nor how it is deployed.
Usually easier to administrate & upgrade than a mess of script files & packages. Especially if you're not in whatever "scene" that junk's from (e.g. you're an iOS developer, mostly, not a Javascript person used to dealing with npm crap, or a Python person used to PIP crap, or a Ruby person used to gem crap, or whatever crap it may be). Download file for correct arch, run file. You can confidently use it even if you're not familiar with Go at all. Even if you hack on it and make your own builds, the deployment story's nice & simple because deployment target images or VMs or devices usually don't need anything but the binary and maybe a service definition file or startup script of some kind (which everything else also needs anyway, so not like that's any worse). No having to make sure npm's installed, then use it to install some native package that needs to build some C deps for the given environment, set the right Python environment, check the Ruby version, none of that junk.
[EDIT] In short, I guess, the nice thing about running services written in go is that, unlike a lot of other popular ecosystems, you actually can forget about what it's written in, more often than not.
If it's used in a small company, one of the users will also be deploying and administering it and integrating it with whatever else the company has. So things like what it's written in, matter.
Fairly anecdotal but feature breakages usually more common in Node apps than Go, it does "matter:most" for end users. It's not because of Node itself but the sheer amount of npm packages what's responsible for those.
