Erlang makes no claims about being fast in these sorts of tests. They aren't using what it was designed to do.

Also some languages like, Ruby, do really well on some of these tests because the C-code underneath has been written well (example regexes are just as fast under ruby as they are anywhere else because the underlying C-library kicks ass though I forget the name of it).

Erlang's claim to fame at least for me is parallelism. When you scale out to thousands upon thousands of clients. Think about the simple fact it was using all cores on a processor out of the box by design that a computer had available. There's also the whole zero downtime aspect. In Erlang you should be able to design software (again downtime from the software side, not much you can do about hardware failure or server maintenance updates to your OS) that if it needs an update it can update itself without killing off anyone connected to it. There's also it's functional aspects.

Erlang isn't built for computational throughput. It's built for concurrency and fault-tolerance.

This is why benchmarks really don't mean much. They are a myopic view of the complex nature of language selection. For example, I would never recommend Java for a bulletproof app that had to scale, because OTP is so much better at scalability, fault tolerance, live debugging, and hot code deployments. At the same time, I would never opt for Elixir for doing screen-scraping, because it is slow at it. Sometimes, developer productivity is more important than speed and scalability. It is important to know the strengths and weaknesses of various languages, and the most important aspects of your project, in order to pick the right tool for the job, I think. Performance benchmarks are but a small part of the selection process.