With undefined behavior, a conforming compiler can do anything it wants at all, including generating a program that segfaults or something else.

But what often happens in practice is that "Bill's Fly-By-Night-C-Compiler-originally-written-in-the-mid-nineties" implemented it in some specific way (probably by accident) and maintains it as a (probably informal) extension. And almost certainly has users who depend on it, and can't migrate for a myriad of reasons. Anyway, it's hard to sell an upgrade when users can't just drop the new compiler in and go.

At the language level, it is undefined-behavior, and any code that relies on it is buggy at the language level, and non-portable.

Defining it would make those compiler non-conforming, instead of just dependent on defining something that is undefined.

Probably the best way forward is to make this an error, instead of defining it in some way. That way you don't get silent changes in behavior.

Undefined behavior allows that to happen at the language level, but good implementations at least try not to break user code without warning.

Modern compilers with things like UBSan and such makes changing the result of undefined behavior much less of an issue. But most UB is also, "No diagnostic required", so users don't even know they have in their code without the modern tools.