There is a general problem with this question in that it is too absolute. It does not really make sense to say "language X is faster than language Y". A computer language itself isn't "fast" or "slow" because it is merely way of expressing an algorithm. The actual question should be something on the order of "why is the implementation X1 of language X faster than implementation Y1 of language Y for this particular problem domain?"
Some speed differences are certainly going to fall out of the language itself as certain languages are easier to implement certain domains than others. But much of what makes an implementation fast isn't the language. For instance, you can't really say "Python is slower than Java" without considering whether you are talking about CPython, IronPython or PyPy. This is particularly true for languages that use a VM as the speed is going to be directly impacted by the quality of the VM.
As an aside, I work with a system that for various reasons can't use JIT on our device with a very popular JavaScript VM that normally supports it. This means that our JavaScript runs far, far slower than it would on a PC with a similar processor. That one change, which is not directly related to the language itself, takes JavaScript from being "a few times slower than C++" to being "orders of magnitude slower than C++" for the tasks we care about.
Also consider is that languages differ in performance characteristics in ways that are not directly comparable. Too many benchmarks just translate a program from language A to language B and don't take into account that languages differ in what features are fast. (You can see this in any reasonable benchmark comparison such as those you link to as they often have notes like "thanks to so-and-so for showing me how to implement it in language Foo.)
For instance, Take this Java code:
for(int i=0;i<10;i++) {
Object o = new Object;
doSomething(o);
}
It would be tempting to "rewrite" this in C++ and compare run times:
for(int i=0;i<10;i++) {
Object *o = new Object;
doSomething(o);
delete(o);
}
The thing is, any competent C++ programmer will immediately see that in C++, this is not the fastest way to do something. You can easily speed things up by changing it to be more appropriate to C++:
for(int i=0;i<10;i++) {
Object o;
doSomething(&o);
}
The point is not that C++ can be fast but rather than writing benchmarks to compare languages is really, really hard. To do it appropriately, you have to be an expert in both languages, and write from scratch in both languages. Even then, you can easily run into to areas where one language excels at a particular task. For example, I can write a version of Towers of Hanoi in C++ that will run faster than Java on any reasonable compiler. I can do that by essentially cheating, using C++ templates, evaluated at compile time (http://forums.devshed.com/c-programming-42/c-towers-of-hanoi-using-templates-424148.html)
The point there is not that I could say that "C++ is faster than Java" because my program returned instantly while the Java version ran for minutes (and hoping nobody noticed my program took a half hour to build.) The point is that for this vary narrow case, C++ is faster. For other narrow cases it might be the other way around. So it isn't "C++ is faster", it is "C++ is faster in instances where you can evaluate the expression at build time using templates." Less satisfying, but true.
Speed differences in languages are mostly about the implementation. Compiled languages are going to be faster than interpreted languages. Compiling to native code is going to be faster than compiling to byte code. This will have much more effect than questions like whether than language is statically typed or not. And of course, good implementations are going to be faster than bad ones.
And don't forget that good programmers are going to produce faster code than bad programmers, often to an extent that quite outweighs language differences.
