They should have crowd-sourced the code for this study with a Top Coder-like contest.
Second, to make the comparison as unbiased as possible, we coded the same algorithm in each language without adapting it to the peculiarities of each language (which could reflect more about our knowledge of each language than of its objective virtues).
They have invited others to fork the code on github and write the fastest possible for each language.
I will be interested to see whether people can whittle down the respective benchmarks.
They wrote the code for each language based on prior knowledge about each language, and/or from likely googling how-to's... far from performant code with any language.
A mild understanding of each language could yield dramatic performance improvements over not understanding it at all.
To make the comparison "as unbiased as possible" would be to code the same algorithm but adapt it to the peculiarities of each language implementation.
I was really impressed with the speed difference they noted between Python and R and the fact that Numba wasn't too much slower than C++ implementations. However, given the state of the R code I became wary of accepting the benchmarks at face value.
I haven't made the jump from R to Python for statistical applications yet. So, this article gave me something to think about. In terms of programmer happiness, I'm willing to live with a little slower performance in Python and not have to spend hours in C++.
The flipside is that it only really results in a speed up for pure numerical code - if you have to use any Python objects, then you lose everything.
In fairness to the authors, though, it seems to me they were asking the equally interesting and rather different question 'which language gives the fastest programs in the hands of someone who is an expert in something other than programming?'
Compiling dynamic languages is not easy: their semantics of having everything dynamic and changeable at runtime resists it. Python is internally compiled into a pretty compact bytecode, but something like a method call is much more involved business in Python than even in C++, and is many times slower.
WRT fundamentalism: most sane open source communities are pretty pragmatic; Python's in particular.