I honestly think that the advantages of FP for concurrency will turn out to be relatively minor and that FP is more interesting as a means of improving code reuse and reducing bug counts. I'm not convinced that the current crop of FP languages are a win in those respects either though, taken as a whole.
Programming languages of the future need to enforce thread safety and mutation semantics as well as they do type safety. Functional programming is a step in that direction.
Nobody's necessarily claiming that a concurrent Clojure/Erlang/Haskell app is faster than concurrent C++/Java one, but they're definitely safer and easier to write.
Erlang does do that, more or less, although Erlang processes are much lighter weight than what we usually think of as a "process" or "thread".
What functional programming does mean right now is that it's much easier to chop your program up into reasonable-sized chunks: big enough that it's worth the overhead, small enough that you can distribute as widely as possible.
In other words, if you think of a functional program as a tree and then expect to run each leaf in its own thread, the overhead will vastly outweigh the benefits. But the functional semantics also allow you to run each of the dozen main branches in separate threads with little effort.
I do this in Clojure all the time.