While I agree that Go is suitable for his examples, it's not suitable for hard real-time. As far as I know, its GC does not have bounded latencies. There are GCs that do have bounded latencies (see the Metronome project for Java's GC: http://researcher.ibm.com/researcher/view_project.php?id=174) which then allow them to be used for hard real-time systems.
This is not really an issue with the language but with the implemetnation and most languages/libraries/OS-es are not suited for "hard real-time" either.
How many people are writing "hard real-time" code? I suspect not many, and yes, for them probably Go is not the right tool at the moment, but also in great part because nobody has needed/wanted to use Go in such environments yet.
Requiring garbage collection is a language issue, not just an implementation issue. (Note that I do not think GC is a bad thing, but it matters a great deal in this context.) Making GC work in hard real-time system is a Hard Problem. I think you greatly underestimate how difficult it is, given your final sentence. Read the Metronome project I linked to.
You are correct that not many people write hard real-time code; it's generally found in such things as software controlling planes, power grids or power plants.
Go could do a recording type application with minimal guaranteed latency just fine, and the GC won't stop it doing so.