You could even statically compile a binary and JIT on top of that based on runtime profiles. That would probably be the winning combination performance wise.
JIT can remove code from inner loops that is unnecessary for the current invocation. It can also use any instructions available on the CPU it's running on. It can use more registers if the CPU has them.
JIT advantage is higher performance, which is mostly untapped today.
I don't care about winning any points. I just want people to understand it's not black and white. JIT as an acronym causes them to jump to conclusions without even thinking about it.
Statically compiled code is suboptimal for all but the idealized case the code was compiled for. It has to take general case into account. Wasting cycles checking the condition that's always false anyways for current problem. Setting up the inner loop that's executed just once or twice every time.
A JIT can spend a few microseconds optimizing for that and running the code for 10 milliseconds. Instead of running the generic statically compiled case for 20 milliseconds. JIT can produce code more native than the "native" statically compiled presentation.