I disagree. About a decade ago I made some tooling to extract and analyse code from Haskell packages. That's easier said than done, given the use of pre-processors, TemplateHaskell, language extensions affecting the syntax/grammar, using external files like `.cabal` to specify such pre-processors/extensions, etc.

I went through several iterations, to get something that I could throw arbitrary packages at from Hackage, GitHub, etc. The result was a hacky mess containing a GHC plugin to dump Core code, a library to dynamically generate and evaluate strings of Nix to handle dependencies, shell scripts that piped `:t` commands through GHCi, and so on.

It was annoying, not because of the effort involved (I was doing weird, bespoke things; so it's no surprise it needed weird, bespoke code to be written); but because all of the functionality I needed already existed, just buried deep inside GHC/Cabal/etc.

Admittedly the GHC API has gotten much better in recent years; but there's no way the developers of "one tool to rule them all" can predict all of the different things that users will want it to do. Indeed, it's probably wise for such tools to avoid supporting/maintaining particularly weird/niche uses!

Having a collection of tools instead, which "do one thing and do it well", side-steps that problem entirely: users with weird use-cases are empowered to plug things together in a way that suits their needs, without needing the devs to add special features/flags just for them (or maintain their own forks with such flags, etc.)