It's that you can _quite easily_ write a triple A game without using a managed language.
For games, managing memory is not a big problem. For other kinds of apps, it can be. In some apps the lifetime of an object is not well defined. But in games, it tends to be very well defined.
If you want a good explanation of the problems game developers face when trying to use GC, go read Rich Geldreich's post on it (http://richg42.blogspot.com/2015/05/lessons-learned-while-fi...).
Also, Naughty Dog's games do _not_ use Lisp, they use a custom language that looks a little like Lisp, but has no garbage collector.
An example was Thinlisp, which tries to be mostly compatible with Common Lisp, but without GC. The compiler for Thinlisp is written in Common Lisp.
G2's Gensym is written in such a Lisp. Thinlisp also comes from them, IIRC. http://www.gensym.com
Some Lisp don't/didn't use a GC, but reference counting or similar schemes.
This has been happening for a long time with Java HotSpot and Azul C4, which still represent the state of the art. Go isn't really doing anything new—it's still not generational, for example.
Perhaps the question is still open whether properly managing allocation, using object pools as well as other strategies would enable writing triple A games with a managed language.
Or perhaps all we need is a GC race (à la JS engine race we've seen in the major browser) which Google might very well be starting with the recent efforts on the Go garbage collector.