None of this is really true, but it is true that you can often have strict FPS requirements when making a game and dealing with GC pauses can be very difficult.

Overall, I would not recommend that a novice attempt to make a game with very strict real time dependencies in C#. If you understand C# and CLR interactions well you can do it, but the coding style and optimization techniques are not for the uninitiated.

C++ really is your best bet for something with these types of requirements.

The area in which bytecode can gain an edge is with sse instructions and aggressive inlining. When you compile your game for the i386, you can't assume that the processor you target has all the new SIMD (single instruction multiple dispatch) available. Now this isn't a problem on consoles since you know your target but it is on the PC. The JIT compilation can take advantage of these instructions since they can detect their availability at runtime (which is also compile time).

The other neat trick that JIT compilation can do is profile the code as it is running (less costly than it sounds) and inline hot functions. You can't do this with c++ because you can't unlink the code easily. A good example of this technique is found in the V8 javascript engine.

This isn't to say that bytecode is always faster but rather to point out that using intermediate bytecode doesn't always carry a high performance penalty. What kills C# are the GC pauses. Also keep in mind that nothing can ever beat well optimized assembly for a target processor but the people who can do this are rare and valuable.