Moreover, it is untenable to maintain a small island of "secure software" for "important things" in a vast ocean of careless and vulnerable code. Inevitably, the island gets infected, and not even air-gaps can save it, as stuxnet showed.
Why is it inevitable? As long as it doesn't connect to other software (via internet or other means), isn't it possible to formally verify one critical software component, e.g. in pacemakers?
I'm not saying that C would necessarily be the best choice for formally verifying it, though.
perfect is the enemy of good, "security" people act as if all breaches are equally relevant.
When your surface area is everything you're more likely to have holes, that's just a law of nature. Limit your surface area and suddenly you can be more thorough.
Unlike what your sibling comment claims, I'm not saying all software is equally important, or must have equal effort invested in securing it. But insecurity absolutely is infectious, and the more insecure the general environment is, the harder it is to secure a small part of it.
For example, you'll want a compiler. How secure is the web stack of the page that delivers your gcc/clang? How secure is its host's infrastructure, and of the DNS provider? The browser you're downloading it with? Did you ever visit any other page that might have compromised it? What about your text editor, your OS, the SDK you're using to flash code onto the pacemaker.. And all of them have vast supply-chain networks.
This idea that all code must be treated equally wrt security is why security people are oddly never effective.