from the original document: "critical code is written in C." The document is not dated, but it's probably quite old (I'm guessing 30-something years). Writing critical code in C is probably a mistake, but once you find yourself in that situation, you will find these rules are too tight (which is also what the criticism is about). You should probably read them as "try to avoid ...".
So I would just prepend the document with "Rule 0: Try to avoid writing critical code in C."
Sometimes, eg aspects of automotive functional safety, MISRA C might be all you get.
These NASA principles are more about enabling better possible static analysis of the code and ease of someone else, maybe decades later, debugging or pushing changes to something likely on another planet.
Also you have to remember space based computing lags well behind terrestrial computing because of the radiation hardening. They are often still dealing with legacy systems that might be 8 bit with very limited memory, they were still in the hardware expensive engineers cheap mode until well into the nineties, if not later. Rad750s run at 400 mips and were, and maybe are, preferred choice of processor.
These days, there are compilers for embedded systems that can prove for certain code (for example) that it runs in constant time and constant space.
As an example, galois.com has been doing this for Haskell, not just for embedded systems, but also for even more low level things like FPGAs.
So I would just prepend the document with "Rule 0: Try to avoid writing critical code in C."