Though, in fairness, Erlang has a completely different emphasis than most other functional languages - instead of provability, experimenting with type systems, or state-phobia, my understanding is that it was pretty much engineered for making stable systems, and everything else is a secondary concern. (It was also put together by a telecom, rather than academics or hobbyists).
It is kind of interesting that unlike many of the "exotic" languages in the list Erlang has arrived where it is from another direction -- from practical necessities of telecom platforms. But interestingly it has arrived at similar results as many academic functional languages. So for example, all base data structures are immutable and variables are single assignment only. Now someone coming from C(++) or Java will hate that, but that is needed in order to provide stability and a consistent view into the data structures in a concurrent environment. So "fixing" it and making data structures mutable would break that.
Then I like how you said 'statephobia'. In case of Erlang they saw the practical difficulty with having one single mutable state across a large distributed system so applied the 'actor-based concurrency model'. Perhaps other, more academic languages, decided to cure their statephobia because of some aesthetic desire, maybe they wanted the functions to look more like math functions, but they both declared war on spreading mutable state, even though they started from different ends of the spectrum.
When talking about the design philosophy of Erlang, it helps to remember that it was originally implemented atop Prolog, so some of those choices may not have been intentional.
