I don't find Go as nice a language as Python, but it is not terrible; in the past I've called it 'Python with performance'. What makes it especially attractive for sysadmin tools, at least for me, is how it simplifies deployment. Python deployment has three problems: the actual Python versions on various different systems, the availability of additional modules on those systems (and their versions), and actually packaging up and shipping around a modular Python program (cf, and loading zipfiles is not quite a full solution). As a compiled language without any real use of shared libraries, Go makes all of these go away.

Getting away from modularity concerns is frankly a big issue. Python makes modular programs just awkward enough that it pushes me away from them for small things, even if the structure of the problem would make modularity sensible. Because it's a compiled language, Go obviates all of these issues; regardless of how many pieces I split the source up into, Go will compile it down to a single self-contained binary that is all I have to ship around and run. Closely related to modularity concerns is use of third party modules and packages. Again Go needs these only at compile time and they can be in my own build area; I don't have to worry about what's installed on target systems or available to be installed through their local package manager. If it makes my program better to use some Go package, I can.

I also don't have to worry about Python versions any more or in fact the development environment in general because under most circumstances Go will cross-compile from my preferred environment. Deployment targets can be as bare-bones as they come and it doesn't matter to me because I can sit in a full environment with a current Go version, git, a fully set up Emacs, and so on and so forth. I do need to do some things on the deploy targets when testing, debugging, or tuning performance but nowhere near as much as I otherwise would.

As I sort of discussed in another context, all of these issues more or less go away if you're working on heavyweight things. Heavyweight things already have complex deployments in general and they often want to drag along their own custom environments even (or especially) in interpreted languages like Python; you may well run a big important Python app in its own virtualenv with its own build of Python and whatever collection of third party modules you want. But this is not the world that sysadmin tools generally operate in. Sysadmin tools are almost always small things that don't justify a lot of heavyweight work (and don't have complex deployment needs).