I get your point (and it's a fair one) but what happens when it goes the other way? A bit of code written (and working) in friendly C finds its way into a regular good old C codebase. Suddenly it contains a critical bug that may go unnoticed.
Or some coder is used to friendly C, uses aliasing, memcpy and wrapping arithmetic without thinking twice. Then he's asked to work on some project building with a regular C toolchain. Gun is cocked and pointed at the foot.
Those problems only occur because friendly C is a dialect of C, you don't get those drawbacks if you tell devs to use Rust or whatnot, because the difference between Rust and C is obvious, unlike friendly C and C.
This exact problem exists today if someone takes code from the Linux kernel that is compiled with things like -fno-strict-aliasing. Undefined Behaviour makes programs unpredictable in the first place, given that you can't reasonably ensure you're not triggering it. I would expect a lot more people to use friendly-c (or simple-c or yes-this-is-how-your-cpu-works-c) than standard c.
As he notes, people who need the undefined behaviour-induced optimisations are in the minority.
Such code would also fail if passed to tools like lint, and would result in warnings or worse when loaded in IDEs. The incredible C toolchain built over the decades is one of C's biggest advantages; friendly-c cannot afford to lose even 10% of it.
Or some coder is used to friendly C, uses aliasing, memcpy and wrapping arithmetic without thinking twice. Then he's asked to work on some project building with a regular C toolchain. Gun is cocked and pointed at the foot.
Those problems only occur because friendly C is a dialect of C, you don't get those drawbacks if you tell devs to use Rust or whatnot, because the difference between Rust and C is obvious, unlike friendly C and C.