I don't think C screwed up. C's objective was to standardize a set of practices based on what the hardware of the day was capable of. If they had pessimized performance on one architecture because it failed to provide efficient checked overflow (or any other feature), then C would have never made it to standardization.

ISO C is therefore a three-way compromise between three communities: Software authors, compiler authors, and CPU manufacturers. You will naturally end up with some decisions that dissatisfy some members of each.

Better would be to say that the C standard committee screwed things up by refusing to address a lot of issues over the last 35 years.

Not really, they have addresses pretty much all of the issues. Now, you can argue that they favored compiler authors when doing so, but they have consider the problems and done things in response to them.

Yes. In many ways:

1) it’s pretty important to have easy syntax for math with overflow checks. Otherwise there will be bugs. Bad bugs. We have those and it sucks.

2) it’s pretty important that if the overflow wraps in ISA then it wraps in language semantics but C just says “meh whatever” for signed overflow. That leads to even more bugs.

The HP3000 had "SPL" - Systems Programming Language -- as its way of doing what C does. It had a specific syntax for checking the error codes: if <> then <whatever> so whatever previous arithmetic did, you could check the machine's flags directly. Can't do that in C. https://en.wikipedia.org/wiki/Systems_Programming_Language

At the time C was designed not all machines did represent signed integers in 2 complement. Therefore it was not possible to define behavior for signed overflow. They probably should change that 2020^^

GCC has intrinsics for integer math with overflow checks

C++ formalized two's complement already. Formalizing power-of-two word size and 8-bit bytes might come.