Automatic parallelism is an easy selling point, though.
Haskell in practice sells itself as “purely functional programming”, but the man-on-the-street feels deceived because purely functional is a technical term, #1, #2, functional programming, in an impure form, is pretty normal and standard these days as much as OOP was.
I think Graninas back in the day rehashed “what happened to Smalltalk could happen to Ruby too” with Haskell and Rust, but the analogy is incorrect. Smalltalk was displaced by Java because Smalltalk was ridiculously slow and mandated both a full IDE and a full deployment environment, whereas Haskell is roughly Java speed and is "impure’ in practice.
If, somehow, people were able to make GHC automatically produce parallel code, it would fulfill one of the big promises of functional programming, as well as produce a trivial selling point; Verse is automatically parallel (IIRC), but is dedicated to Epic Games’ metaverse. Haskell could be automatically parallel on top of its excellent parallel / concurrent story, and it’d be a big selling point for commercial adopters through greatly increased ergonomics.
But end of the day, your main point is that adding autoparallelism to GHC is harder than it looks (maybe a custom monad)? Honestly, with effect systems becoming so popular, we really need an alternative to forcing the IO monadic type on everyone and allowing people to have main have other types than IO a and have it be supported by GHC), and I guess it’s a pipe dream as long as this is the case.