> Yet, C is still slower afterward.

If you read the article you'll learn that in the end the author not only states there isn't any practical difference in the results that the author pulled with their ad-hoc test examples but also points out which non-performant choices were intentionally left in the last example that lead to the 40ms difference (which, again, the author states in no uncertain terms is meaningless)

I don't know how anyone can look at benchmarks of two ad-hoc tests with one of them being intentionally and openly sub-optimal and from that point automatically jump to conclusions over performance traits of a whole programming language. Crazy stuff.

Ignoring calling out into badly implemented external functions (like stdlib stuff), solving the same problem in any statically typed and compiled systems programming language should pretty much result in the same machine code output, any remaining differences are down to the compiler implementation, not the programming language.

One of the things that actually can make a difference is different rules for pointer aliasing so that the compiler isn't forced to go through memory in some cases, but as Rust has shown, fixing this on the language level doesn't seem to make all that much of a difference in real world performance.