For me too. TFA is, I think, the first coding standard I came across that made sense to me. Except for the "2+ assertions per function" rule. 2 is arbitrary for one thing, and secondly your top priority, in the context of mildly mission critical embedded code, is to do what it takes to keep your system alive and sane (as fault tolerance people put it). Then log the issue if you can. Downtime caused by a program abort followed by a watchdog reboot should be a last resort for things that you really couldn't possibly expect and therefore cannot handle properly - there's no such thing as an "unexpected error".
Also before that, design things so that errors cannot happen; for instance use C's type system, as weak and clunky as it is, to make it is hardly possible to pass out-of-range parameters. There's a trend these days to bash-at-will C for its "unsafe" nature, but a significant part of the issues are "between the keyboard and the chair", that is not doing the right thing because it is tedious - that's probably the main defect of C.
“2+ assertions” could be read as “a precondition, a postcondition, and maybe a loop invariant”. The guideline should perhaps be more explicit about asserting your pre- and postcondition, but that’s a perfectly natural minimum standard.
As for C’s unsafety — it is a poor engineer who doesn’t account for human factors. A language that doesn’t mitigate PEBKACs, and which lacks affordances to make safe code less tedious, is intrinsically unsafe.
Also before that, design things so that errors cannot happen; for instance use C's type system, as weak and clunky as it is, to make it is hardly possible to pass out-of-range parameters. There's a trend these days to bash-at-will C for its "unsafe" nature, but a significant part of the issues are "between the keyboard and the chair", that is not doing the right thing because it is tedious - that's probably the main defect of C.