I'd argue that you're correct in highlighting a certain tradition but that most arguments about the advantages of Haskell are completely orthogonal to this idea

I'd argue that you're correct in highlighting a certain tradition but that most arguments about the advantages of Haskell are completely orthogonal to this idea. Haskell is more powerful than JavaScript as you can embed JavaScript into the semantics of Haskell. This is where the ideas of existential types and unityped languages come into play. Haskell is sufficiently rich to directly emulate JavaScript as a type-contained embedded language. Thus, all of the same exploration is available. This idea is highly idiosyncratic Haskell. Nobody would honestly suggest it as Haskell guides the intuition of the programmer quite strongly. This embedded language must also immediately throw away much of the machinery and speed of Haskell. The reasoning again is not that Haskell is right but instead that its semantics are a superset of those available in JavaScript. But given this inclusion, most people rarely use features like pervasive state and dynamic typing while programming in Haskell. Part of this can be answered as language convention force and regularity, but these techniques do show their advantage at times. This is what gives the Haskell programmer confidence that they understand the value of many language features: they've constantly redefined "Haskell" in many miniature, well-interleaved parts to be whatever makes sense for the problem at hand and thus have seen the value of a variety of language features. So I'll end by suggesting that once you learn Haskell this notion of "design your own solution" is actually even greater than the one in JavaScript. I don't take this argument to be ground truth, but instead just a challenge. JavaScript and Haskell both allow the programmer great control over the semantics of their language, and Haskell has many mechanisms which give that power greater leverage than JavaScript can.