Here’s the thing, Haskell isn’t actually “pure (functional programming)”. It has support for procedural-looking code (do notation), actually mutable variables (IORef, STRef, MVar, TVar), as well as dynamic types (Dynamic, -fdefer-type-errors), and even objects, via libraries like Hoop and Objective.
What it is, instead, because of how Haskell relies on the IO monad, and GHC relies on State# RealWorld a, is “pure functional $ programming”. What you end up with is a relatively strict isolation between pure parts of your program and impure parts, which in combination with a syntax highly conducive to FP, permit what is sometimes described as algebraic programming, wherein equational reasoning holds.
The problem, though, is that the term pure creates confusion. Both Richard Bird (may he rest in peace) and SPJ have called Haskell “Imperative Functional Programming”. An astute Haskell learner, after jumping through the initial hoops, will realize that Haskell is capable of producing extremely imperative code (I have an allergy to do notation for this reason and use it very sparingly as a consequence).
Perhaps rebranding Haskell as, instead of “purely functional programming”, “algebraic programming”, “algebraic functional programming”, or “purely functional or algebraic programming” might help to avoid the confusion? The trade-offs would be that the line “pure, functional” helps attract people interested in FP for FP’s sake, but how many of them actually stay here? But in a corporate environment, explaining Haskell as “algebraic functional programming” might avoid the notion of purity and (implicitly) impracticality, as well as provide an opportunity to explain Haskell’s IO monad in terms of its benefits in program design.
The point isn’t to abandon the effective “Avoid $ SuccessAtAllCosts” philosophy, because that’s a philosophy of the GHC Committee. The language Haskell will remain Haskell, not compromising simply to seek adoption. But the branding of Haskell might be improvable.