This is considered a practical example?

Regardless, checking a register or hot value already in cache against a constant is free on modern CPUs.

It's not a practical example but it's relatively non trivial e.g. some otherwise good compilers can't figure that one out.

Wait, how does that work? Without overflow, how does the compiler prove that eventually x == 7?

If x <= 7 then the answer will be 420, but if x > 7 then behavior is undefined because x will overflow, and x is signed, and signed integer overflow is UB in C, so the compiler is free to, for example, conclude that blazeit() is never called with x > 7, thus it can prove that blazeit() always returns 420. Besides, if the compiler chooses to implement signed integer overflow much like unsigned integer overflow, then x will eventually come around to 7 anyways, so the answer must be 420.

Then later, after some minor unrelated change, compiler stops optimizing and it suddenly starts overflowing the stack.

How can anyone put up with that?

If you rely on an optimization like this, that's not a code smell as much as a code-sewer:

This is one of those optimizations that a very clever compiler might be able to do interprocedurally give a certain input for example.

I expect the compiler would optimize the tail recursion into a loop, so the likely worst case is not that you blow the stack but that you spin for a while.

Not really, any expectations here are unsupported by C standards. Compiler is, by spec, allowed to do anything here.

The loop (and function) terminates when x == 7, and the compiler can show that x will be 7 at some point i.e. it knows it's on a system with overflowing integers