I disagree. From a user's point of view, hardware-assisted memory safety is always beneficial. As a user of any software, you cannot verify that you are running a program that is free of memory access errors. This is true even when the software is written in Rust or an automatic memory-managed language.
I hope that one day I will be able to enable memory integrity enforcement for all processes running on my computers and servers, even those that were not designed for it. I would rather see a crash than expose my machine to possible security vulnerabilities due to memory access bugs.
From which decade since C came to be, do you wish the example?
Note that C authors were aware of many flaws, hence why in 1979 they designed lint, which C programmers were supposed to use as part of their workflow, and as mentioned above proposed fat pointers.
Also note that C authors eventually moved on, first creating Alef (granted failed experiment), then on Inferno, Limbo, finalising with Go.
Also Rust ideas are based on Cyclone, AT&T Research work on how to replace C.
It was needed the tipping point of amount money spent fixing CVEs, ransomware, for companies and government to start thinking this is no longer tolerable.
My point is focusing on the language is inherently missing the point, which is simply incorrect code.
It's like saying airbags, seat belts (and other safety features) in cars are a terrible mistake because they just fix bad driving practices.