I can see why it would be bad for drivers, but why games? Functional programming has started to become popular in that space lately, and for good reason
> Haskell is a garbage collected language, so Haskell is more appropriate for the scripting / logic layer of a game but not suitable manipulating a large object graph or for implementing a high-performance game engine due to the risk of introducing perceptible pauses due to GC pauses. Also, for simple games you can realistically use Haskell for the entire stack.
None of that is a showstopper. But I'd rather use a language that doesn't suffer from fundamental drawbacks on the domain I will work.
That said, Haskell is very promising for AI. If I ever get to that game again, I'm writing the main loop in Rust with an asynchronous AI in Haskell.
Action games are thus fundamentally hard-real-time systems.
One technique used for writing games to run on GC'd runtimes is to avoid allocations entirely in the game loop. With a lot of work, you can preallocate everything you're going to need and just modify it as you run.
This technique is not a good match for Haskell's primary design principle of avoiding mutable state.
If your game has real time dynamics, it's not worth it. If it's some turn-based one without animation, it's not a problem.