Having to enable them in the code is just a hassle. Just make it official and be done with it, just roll it into the language.
If you're suggesting that _every_ GHC extension is enabled then I think you don't really understand the implications of that. Many aren't compatible with each other in varying degrees, for one. They also exist on a wide range of stability and production readiness.
On the other hand, I agree that the extensions indeed hurt Haskell. Standardizing on them is absolutely necessary to survival for a team of even a modest size. GHC2021 and GHC2024 help to do this for the community at large.
The real "deep" change that I think would be best for Haskell is probably impossible - that would be for GHC to split into two compilers - one for production use and one for research. I don't even know HOW we'd do that but I think that's ultimately what us production users want in some form or another.
And those features are not a library that you just throw in, they are compiler specific.
the only other haskell compiler is MicroHs. and it has no pragmas. it just enables the whole thing.
this is not a real problem in practice. even without the GHC20XX stuff (which is nice). it feels like a problem a novice would point at (and be totally wrong)
sorry your favorite language doesn't let you import language features according to your needs. half of them have trade-offs! like -XOverloadedLists. Useful, but hurts inference. Maybe you don't want it globally. But maybe in a few modules, it's perfect. {-# LANGUAGE OverloadedLists -#} is the answer that no other mainstream lang has.
-XPolyKinds is another great example of that sort of extension.