Well, as other posters have pointed out, lisp is multiparadigm, not just functional.
Anyway your question was more about abstract concerns, but concretely, note there are pretty decent SDL and OpenGL bindings for common lisp, and mildly optimised native compiled lisp code borders on "fast enough" for fast-paced 3D games - I mean people write fun games in Python these days, never mind lisp! even if GC is not concurrent, GC pausing is much less of a problem than people make out with a little common sense and care, - prealloc object pools before levels begin, code consless or at least cons-lightly, perhaps even go ahead and disable GC runs except at inter-level breaks...
IMO CLOS is a very nice object system for game code in an object-oriented style due to multiple dispatch (see wikipedia example):
http://en.wikipedia.org/wiki/Multiple_dispatch#Common_Lisp
http://lispbuilder.sourceforge.net/lispbuilder-sdl.html
http://common-lisp.net/project/cl-opengl/
When I last looked a while back (it might be neater now), the secret to getting cl-opengl and lispbuilder-sdl to play nice together was the following incantation, enabling use of opengl 2 shaders and stuff:
; N.B. don't use any ext. functions which go through GetProcAddress
; until AFTER an opengl sdl surface exists, presumably there's late binding going on...
(setf cl-opengl-bindings:*gl-get-proc-address* #'sdl-cffi::sdl-gl-get-proc-address)