Their secret is they keep the game state heap really small. Like, 50 megabytes, maybe.
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.
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.
Given that a Go 1.6 GC will still take about 4ms, you have 12.7ms to generate a frame, which can be too limiting for some CPU-intensive games, but is perfectly acceptable for many games.
(In Go 1.5, a GC was much more likely to make you drop a frame, as it could easily average 40ms.)
On the other hand, there are less high-quality libraries in Go than in C++ or in JS. That may be the most limiting factor.