I spent over two years working every day with Erlang on a project, and I still don't consider myself to be anywhere near an "expert" at the language. It's just too weird and special case for a lot of the functionality I was trying to code, so while certain tasks were easier than they would have been in Java or another procedural-object language, others were damned near impossible and took obscene amounts of time to get working at all -- never mind working efficiently.
Personally I'd avoid it like the plague unless you have some special case need for it's features. Even with regards to concurrency, it's not really any better than any other language's concurrency features. They aren't really baked into the language as the summary suggests, but provided by frameworks in the API libraries, much as they are by other languages.
The main difference with Erlang concurrency is that the concurrent models are the "normal" way to program Erlang, so you're likely to find a lot of good examples of how to do it. I've found the documentation for other language's concurrency features to be somewhat limited in comparison, and less "real world" in their examples.
The main thing that I found neat about the Erlang framework was the ability to specify auto-restarts of failed threads. It takes all of about 4 lines of configuration to get a thread to be persistent/self-starting. That's the densest code I've ever seen for achieving such a task.
The big downside to Erlang is that it's almost as bad as LISP -- everything is a list. Even "structures" are just lists of objects with tags that identify the list indices for accessing the members. Be prepared for a nightmare of tail recursion if you get into this field of programming.
That said, it can be a fun and entertaining language to work with. For the things it is good at, it can be a joy to use. Much as with any language.