The new versions of C# can compile ahead-of-time, and have expanding support for value types and pointer-like semantics, so you're not stuck with the Java-y OOP For Everything paradigm if it doesn't fit your requirements.
The standard libraries are still an allocation party, of course, but that can be supplemented in an engine context.
Famous last words, even with the optimization in the latests net core clr, it's nowhere close to C++.
Citation needed? Raw speed is likely similar; the cost overhead comes from GC cycles and the general approach to managing memory primarily in the heap vs stack, although C# can stackalloc if you're really diligent. Note that this is the same problem that blazing fast alternatives like Go have at competing with C/C++. These languages are mostly equivalent to C/C++ in speed, but lose the benchmark shootouts because of GC.
Calling Go blazing fast would be a stretch at best...the path to performance in C# is same as in Rust or C++: struct generics (aka templates), as short hot paths as possible, static partitioning of the work, sometimes hands on memory management and minimization of locking.
This is a pretty wild generalization to make. It's not hard to contrive scenarios where C++ with its notoriously slow stdlib (despised by game developers) is going to be slower than C# with its JIT doing runtime optimizations like guarded devirtualization.
C++ written by people who really good at writing fast C++ is faster than C#. Naive and readable C++ written by average programmers wanting to solve a problem in the obvious way on the whole isn't faster than C#