E.g. any app with [record] button need to meet 'mostly' predicted system latency, that's 'soft-real-time'. Any professional app with [play] and [record] button needs a minimal warranted latency, that's 'hard-real-time'. Go is unsuitable for both.
Hard real-time generally means that you have an actual deadline to finish your computation, and Very Bad Things will happen if you miss that deadline. Both of your examples are soft real time.
Go could do a recording type application with minimal guaranteed latency just fine, and the GC won't stop it doing so.
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.
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.
import "runtime"
...
runtime.MemStats.EnableGC = false