Haskell (or any other pure functional language) can often make it viable for you to write code that is much more performant than what you'd have writen in C (or any ohter mainly imperative language). Mainly so if the problem is paralelizable and can use asynchronous IO.
Done. Now you've seen somebody arguee that functional programming is benefical for performance reasons.
Of course, the previous statement is not true if you have unlimitted budget and time. At least not yet.
The argument paraphrased is "we've maxed out what we can do in a serial fashion, so we need to start working concurrently and/or in parallel. Functional paradigms are much easier to reason about concurrency so we switch to them for the win!"
Functional programming in general tends to be better in terms of cache locality and number of dereferences required. Largely because it tends to encourage storing things "column-oriented". Ever looked at cache locality and the number of dereferences required in an overly-object-oriented program? Not pretty. Pointer chasing all over the place.
Although this is more of a push away from OO programming than a push towards functional programming. OO implicitly assumes RAM - and in modern computers memory is decidedly not random-access.
"Functional programming in general tends to be better in terms of cache locality"
I've seen no evidence to support the "in general" part of this claim. I will agree that pointer chasing kills cache locality and that in some object systems dereferences have a bad impact on this. But in many functional systems you encounter the same problem with cache locality due to the nature of immutable data structures.
