That's not what I mean. The C standard contains some rules that exist for the sole purpose of providing better optimization, and some of these rules give raise to undefined behavior. The compiler leverages undefined behavior by allowing optimizations to not have to care about code that exhibits such undefined behavior.

If compilers did not take advantage of this, then a lot of behavior would not have to be undefined in the first place. Undefined behavior isn't conjured up from a magical place, it was deliberately specified for a reason.

The subject of the linked article, strict aliasing, is a prime example of exactly that: Surprisingly strict rules for aliasing, giving compilers the opportunity to better optimize code that follows these rules, at the risk of breaking code that does not follow the rules in arbitrary and perhaps unintuitive ways.

Now, these particular rules are controversial, and the article acknowledges this:

    If you read this document, you may find to your horror an awful lot of C code, probably code you have written, is UB and therefore broken. However just because something is technically UB doesn’t mean compilers will take advantage of that and try to break your code. Most compilers want to compile your code and not try to break it. Given that almost no one understands these rules, compilers give programmers a lot of leeway. A lot of code that technically breaks these rules will in reality never cause a problem, because any compiler crazy enough to assume all code is always in 100% compliance with these rules would essentially be deemed broken by its users. If you are using fwrite to fill out a structure, you are just fine. No reasonable compiler would ever break that code. The issue is not that implementations don’t give users leeway, the issue is that it’s unclear how much leeway is given.

Nevertheless, there are many other rules that are much more readily accepted where similar things are taking place.