It is not just about Erlang, but any language+runtime which has been designed upon a well-known set of sound principles (immutability, share-nothing, message-passing).
As long as order of evaluation does not matter (for a pure-functional code) some [major] parts of a program could be evaluated in parallel by runtime without any changes in the code (especially when a high-order function composition - map/filter/reduce/etc is the primary pattern). So, Haskell, for example, will do it too.
By "will do it" you mean "would, in theory, support a compiler that parallelized significant amounts of idiomatic code with no source changes"? Maybe. I don't think any existing Haskell compiler does that, though.
Haskell will do what? Automatic parallelization of code?
The big difference between Erlang and Haskell is that Erlang fundamentally encourages the programmer to think in terms of individual processes that communicate by message-passing. Programmers have also been taught that spawning processes is cheap so idiomatic Erlang code typically have tons of them.
I love my haskell brethren dearly, but haskell isn't organized structurally around an essentially-mandatory fundamentally concurrent, debuggable, quasi-preemptive core like OTP. Not that it won't get there eventually (cf. Cloud Haskell) but it's more than just being able to run concurrent threads. Note: this is not a language flame, just a personal opinion/observation, and I love and welcome correction.
Haskellers like to pick and choose their abstractions. That's why we have MVar and TVar (STM) and IVar and locks/semaphores and unbounded channels and bounded channels and software transactional channels and green threads and Async and OS threads…
You're going to see what Erlang did atomized, implemented piecemeal, and reconstructed. Cloud Haskell burnt too much goodwill in pursuit of a mostly pointless feature.
That's how we ended up with slave-thread…the beginnings of supervisor trees.
Haskellers would rather pick and choose. It's worked well so far.
You are right. Haskell is an academic research vehicle while Erlang is a pragmatic "industry-strength" (i hate these buzzwords, but they are useful generalizations) functional language.
In theory, we could re-write almost any part of OTP in Haskell, in practice, however, "runtime is hard" and the biggest selling point of Erlang is that its runtime and standard library (OTP) has been evolved for almost 20 years and is based on the same principles of a functional language (except, perhaps lazyness by default) as Haskell.
In other words, while Haskell is a "playground for researches of type theory in context of programming languages and compilers" Erlang/OT is a "telecom industry-standard toolkit".
A close analogy, in my opinion, could be the pair of Scheme/Racket and CL. The first was mostly an academic teaching and research tool, while second is a pragmatic (but unfortunately bloated) tool-set.
As long as order of evaluation does not matter (for a pure-functional code) some [major] parts of a program could be evaluated in parallel by runtime without any changes in the code (especially when a high-order function composition - map/filter/reduce/etc is the primary pattern). So, Haskell, for example, will do it too.