No sane game developer would use anything other than Assembly.
The more things change, the more they stay the same.
"It'd be really cool" was absolutely sincere; the Go folks have given us some new toys and it'd be neat to see how far we can take 'em.
The culture in the gamedev world is such that the big teams only switch tooling when forced to do so. Only amateurs tend to try out new ways.
Back when the move from Assembly to higher level languages started, many games would be filled with inline Assembly.
The compilers weren't that good generating code and they didn't want to loose the power of Assembly.
Just like now with the managed runtimes and having tons of C and C++ underneath. Languages that weren't that speedy 30 years ago.
We need to keep the spirit of taking things far alive, because in computing seeing is believing.
One approach is just to program as if you had less CPU, as if there were always a GC running. I suppose if you have some code that isn't smoothness critical (game AI, say), or CPU-affecting detail settings you can twiddle without looking too glitchy, maybe you can figure out some way to shed work when you start to fall behind.
It'd be really cool to see someone attempt a game or such in Go--boundary pushing's always fun, more so when the boundaries are recently expanded.