> many people assume that the answer to “is x faster than C?” to be “no” for all values of X.

This is because C does so little for you -- bounds checking must be done explicitly for instance, like you mention in the article, so C is "faster" unless you work around rust's bounds checking. It reminds me of some West Virginia residents I know who are very proud of how low their taxes are -- the roads are falling apart, but the taxes are very low! C is this way too.

C is pretty optimally fast in the trivial case, but once you add bounds checking and error handling and memory management its edge is much much smaller (for Rust and Zig and other lowish-level languages)

In the real world the difference is rarely significant assuming great programmings implement great algorithms. However those two assumptions are rarely true.