I tend to complain on Go's design decisions and don't have any actual use for it, but given my experience with Oberon, I do believe there are use cases where it would be possible to use Go as systems language.
For sure not in when targeting 8 or 16 bit CPUs with a few KBs, or timing constraints that cannot deal with possible GC pauses.
But for more beefy micro-computers like the original PI, it can certainly be an option.
This would a good starting point for anyone trying to attempt it
http://wiki.osdev.org/Go_Bare_Bones
Also I consider the ability to write compilers to be systems programming use cases and Go is already bootstrapped.
Having said this, yes there are better options to do systems programming with less need of Assembly help.
After posting, I realized its concurrent programming model, is another thing which I (and many others) am a fan of. I found the channel and go based approach, much better compared to explicit spawning of threads in languages like Java and C++.
Language consistency (no magical functions like "make" or magical items like slices), DRYness (generics), better type-safety than C (interface{} is the void * of the 21st century), would be a good start.
Due to the mandatory GC, it's also not a C replacement where C is good at. Hence the backtrack on "systems", etc.