That's an interesting link, but a bit meaningless because:
1. It does not specify what C compiler was used (and what version), what compile settings were used, etc.

2. There is also the possibility that the porter changed some things here and there to make better use of newer OpenGL things that were not available back in 1997 when Quake 2 was programmed.

3. A lot of the CPU time is spent in external APIs (OpenGL) rather than in the game code itself. I would guess a software only renderer will show more interesting results.

Anyway, the main reason why I don't believe VMs/JIT will ever catch native code in terms of speed is because it's a bit like the telephone game.
In a C program, you more or less tell the CPU what to do, step by step (assuming the compiler is smart enough not to do really stupid things). You can even use custom ASM in C, you can use registers for variables, and so on.

For Java, the compiler will translate stuff to virtual code (one step) then the JIT will translate that code in native code (another step). The more steps you have in a process the least likely it is for the final code to do things the way you want it to be done, and there is more room for errors (errors as in making the code less optimal).