I'm not sure I've met anyone with significant application security experience who would claim writing correct C is anything less than very challenging. It's not just memory safety, even basic features like iterable collections make code easier to write while at the same time avoiding potential bugs (vs C for loops in this case).

Security is tricky because correct programs (including in C) can have security problems, like side channel attacks and whatnot.

You can write code which you think erases some security-sensitive information to zero bits after a calcualtion, but the compiler throws it away. The program is perfectly safe in that it doesn't crash on any bad input or miscalculate on any good input, but doesn't meet a security requirement.

The crux is that what the language standard calls "observable behavior", and behavior that can actually be observed (with security implications) are two different things.

All C is unsafe, because it's a property of most language features. E.g. this is unsafe:

  int main(void)
  {
    global_init();
    service_loop();
    global_cleanup();
  }

Some of these functions, defined in another translation unit could require parameters, but their declarations be incorrect or missing from this translation unit. So the program will link, but the behavior is undefined.

"Unsafe" means that "no diagnostic is required when a rule is broken". When correctness depends on the programmer, such that the tooling silently accepts incorrectness, that is unsafe.

Almost all C is unsafe, but not all coding situations are equally risky of having a problem.

Under this valid strategy we minimize writing C. When we do right see it's easier than writing the unsafe Rust equivalent (if we are to believe the submitted article).

People working in non-Rust languages, I'm writing just small amounts of low level, unsafe parts in Rust, would be better off using C.