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#