This big question is -- what is the compelling use case for another major Haskell compiler?

Any intractable problem with GHC is a compelling use case for another major compiler. Such problems include an intimidating and difficult build process, messy APIs and inconsistent/absent documentation of the internals, unfortunate design decisions like making all error messages built from strings to such an extent that its main author is afraid of changing it, being really slow at code generation, not supporting anything that was invented by Lisp and Smalltalk programmers in the 70s and 80s like live image update and data type migrations, having so many levels of code generation that going from "here's what I wrote in my editor" to "here's the assembly generated for that expression" is apparently pipe dream, rather than run-of-the-mill as in other compilers of high level languages.

Fay isn't my baby anymore, but while it still has users, people are more sold on GHCJS nowadays (including myself) due to the feature-completeness, but what attracted people to Fay and contributing to it was the simplicity of the compiler. Hugs is a simple compiler. It's a simple C codebase and I've hacked on it. Building it is trivial. Idris is similar. Look at the leaps and bounds made in just being a decent editor environment made by Idris. Being an approachable codebase is a feature all of its own. The last three times I tried to build GHC I had inscrutable build errors.

I don't want to get into the monolithism vs modularism debate because that depends on the use-case. But it's clear that GHC takes the monolithism approach. Why, for example, isn't there a ghc-parser, ghc-simplifier-and-type-checker, ghc-core, ghc-code-gen, ghc-compiler, ghc-interpreter, ghc-package, etc.? I know as fact that people would love if it you could use GHC's parser, simplifier and its type-checker and generation to core without needing all of the other stuff. You want a banana and you got the gorilla holding the banana and the jungle that the gorilla lives in. That means writing any compiler with GHC is to accept the monolith and to understand a huge landscape of modules and types, and to accept the large library that comes with it if you want to deploy something. If there were modular libraries then you wouldn't need "plugins", you'd just use the libraries.

That's not to say I'm not happy with GHC being the One True Compiler, while Common Lisp's 20 year old spec hasn't changed--even to include sockets or threads--and that has given way to allow compiler writers to really hone how to make a quality CL compiler that are really impressive feats of engineering, it also leads to "portability" issues, no "obvious" choice for newcomers, and the language never evolving. At least Haskell, like Perl and Python, has a flagship compiler that leads the way, responds to community needs (I've seen so many things I've wished for appear in the compiler over the years) and is heavily influential to the standard (descriptivism vs prescriptivism). GHC is also a feat of engineering, I personally just wish I could make use of the fruits of that labour better.