Undefined behavior is defined as 'it does what it apparently does without guarantees to future behavior'. So that code that you should write and that an 'expert' would write that implements something that depends in a non-obvious way on undefined behavior (and it is surprisingly easy to do that) will possibly break in hard to detect ways (if it is detected at all, which is more dangerous) at some point in the future when said undefined behavior is changed.
The only way to work around that is not just by becoming an expert at the language but also by becoming an expert at the implementation details of the language and that's a domain that not many programmers are comfortable in. That way you can make sure you stay away from the undefined behaviors as much as possible.
Bad car analogy: not only do you have to learn how to drive the car, you also need to know that the combination of wind across the left front+rain+loud music on the stereo will sometimes cause a wheel to fall off. This is not usually considered a useful level of knowledge and so C programmers (experts too) all find that their knowledge of the limits of C has a partial overlap with the real limits of C as implemented by their particular toolchain. And in between the cracks lots of nasty stuff can happen.
Dead code elimination, different sequences of optimization phases (changing from one compiler to the next) can introduce very subtle bugs in your code and I highly doubt 'most experts' would know how to distinguish between some very innocent code that will almost certainly bork on some standards compliant compiler with optimization 'on' or 'max' versus similar looking code that will work just fine.
C is a beautiful but somewhat tricky mistress.