And x86 assembler is perfectly capable of expressing pure functions. Such algorithms are still expressed using subroutines, subroutines that save and restore all state to its start state.

The question isn't whether a language can express an algorithm, Church and Turing already proved that. The question is whether the language can do so scalably. We want to see nontrivial examples of FP applied to messy, side-effect-laden domains in a way that rivals other representations for clarity and maintainability.

Depends on what you mean by "scalable". Given that Haskell can track the use of effects and mutable state in its type system, might suggest that it allows such techniques to scale beyond a language that does not. Haskell also has syntactic and compiler support for imperative code, no encoding is necessary, so I don't think your analogy of writing FP in assembly is fair. Writing imperative code in Haskell is much the same as in Java.

I'm not saying that Haskell is as bad at imperative as assembly is at functional, just that being able to accomplish all tasks in a single-paradigm language does not constitute proof that the language is suitable for all tasks.

I love FP concepts, and I've enjoyed my experiments with Haskell. What I object to is that FP advocates don't push FP as a valuable addition to a larger toolbox, they push it as a single paradigm to rule them all. For daily work, I prefer a multi-paradigm language that allows me to choose a programming model that matches the domain well.

(FWIW, I have the same problem with OOP advocates who try to squeeze everything into a class. Some things are better modeled as pure functions.)

I don't think modern Haskell is a single paradigm language. As I said above, it has good support for imperative programming and lots of imperative code has been written in Haskell. Even the GHC compiler is full of imperative code and uses algorithms with mutation where it makes sense (e.g. unification).