[1] not to C.A.R. Tony Hoare levels of "provably correct" , the other sort of correct.
Pre-open source, I never saw buffer overflows. When I was dealing with full time, professional 'C' coders, this didn't happen. Because we all talked to each other and taught each other how to not do that. It's like any other skill or bundle of habits.
I did see the odd "signed integer going negative" or other integer overflow problem, but that was much more about broken analysis and flawed testing. Yeah, it took a little more time to make sure this was the case, but it was just required.
Might be cheaper for next shop to just pick a language that's easier to do correctly. Someone giving that hard look as you stated saying, "Bro, have you even heard of Ada, Go, or Rust? And you still want to suffer through making a robust app in C? Why!?"
Do Go, Rust, or D programmers really fantasize about their language replacing C in any other context than their own work? The article setups up a huge strawman of a caricature of a person to start and then uses really rather spurious arguments to take pot-shots at that strawman.
But just some easy ones, right off the bat:
"C is not a language for programmers that need to be babysat"
I think the number of buffer overflow exploits that we have seen in the wild over the years indicates that C programmers really do need to be babysat. If you're starting a project and you say "let's do it in C", the rest of your team needs to be taking a really hard look at you and asking, "and just who do you think you are?"
I have never met anyone who knows how to program in C "correctly", because those that have opinions on how it's done always seem to be at odds with some other cohort that is equally convinced of their own superiority.