> Also typically language extensions are pretty simple, single purpose, and well documented.
I will try again to explain with an example how these extensions are borderline user-hostile.
One of those extensions in your article linked above is apparently something called `DoAndIfThenElse` which enables if..then..else syntax with if and then on the same line, so far as I can tell [1].
When building programs that assume this extension without declaring that pragma, you get helpful error messages like "Unexpected semi-colons in conditional" [2]. Dealing with oddities like this seems to be routine any time I work on a Haskell project that's not a tutorial, and the constant need to go hunting for these error messages and add random pragma headers saps energy and is discouraging.
There also seems to be an open issue about the extension being undocumented [3], which would seem to contradict your "well documented" claim.
Given such significant problems in a relatively simple extension, I cannot even imagine how bad things are in more complex cases. I think whoever is steering the ship in Haskell/GHC land should really focus on ways to freeze new language extensions, and make the current ones well-documented in addition to providing options like the one you linked. Newer languages have environments that are much friendlier towards newcomers in terms of both documentation and (for lack of a better word) runnability of real-world code.
----------------------------------------
[1] I would really like to know why this is considered a popular language extension, and/or why it was needed, but let's skip over that for the moment.
[2] https://kseo.github.io/posts/2014-01-13-DoAndIfThenElse-lang...
[3] https://gitlab.haskell.org/ghc/ghc/-/issues/18631