Some of that is sadly C having bad defaults - like people ending up using signed 32-bit integers (i.e. `int`) to index arrays on 64-bit platforms, which keeps signed integer overflow UB relevant, for optimizing typical indexing C code.
Both C++ and Rust use pointer ranges for iteration, and Rust even forces indexing/counting to use pointer-sized unsigned integers.
So Rust turned off the LLVM bit which says "signed overflow is UB" and did not really lose much from it (AFAIK, anyway).
It's an interesting talk, but, just for example: architecture dependent behavior is not something anyone really wants to prohibit in C. It's hard to believe, that DJB, who writes sophisticated C code that calls out directly to Intel vector operations thinks that should be machine independent. And his API analogy is wrong. If you have an API that responds to out-of-contract parameters by, e.g. rewriting code it is a bad API. People do fuzzing tests specifically to find badly implemented APIs that don't reject bad parameters. In particular, imagine an API that does one thing, the thing you expect, when called without optimizations, and breaks your program when "optimized"! I got to the node example and gave up. The compiler is not asked to check program correctness.
Both C++ and Rust use pointer ranges for iteration, and Rust even forces indexing/counting to use pointer-sized unsigned integers. So Rust turned off the LLVM bit which says "signed overflow is UB" and did not really lose much from it (AFAIK, anyway).