Wouldn't the garbage collector be a problem?

Performance tuning in a garbage collected language is a slightly different skillset, but a lot of tools are the same (knowing how/when/why you allocate memory, the space complexity of your algorithms, etc). Sometimes it is easier, because generally a good GC wants to help, and isn't just an opaque black box but full of information about the memory usage of your app. There are fewer "knobs" to tweak in a GC language, but that doesn't mean "no knobs", and the focus on data structures, data usage, and (space complexity of) algorithms is a shared problem in the performance world, GC language or not. It seems well past time to stop thinking of GC languages as a "problem".

You can hit 60fps without too much difficulty with GHC's default GC. You just have to take some care about allocations and working set (maybe do some work to move stuff into compact regions or off-heap via FFI) and maybe write some critical path stuff in C.

And the new latency-optimized GC landing in GHC 8.10 will help as well.

No different than gamedev on the JVM or other GCed runtimes.

Not really. Minecraft, Unity engine, anything in Lua/python etc uses a GC.