I also think it was mostly mistake, but was trying to provide what I imagine was the idea at the time.
That said, I think defining things as implementation-defined is only really useful when you have specific feature-check macros you can use to determine the behavior.
Otherwise you are kind of just trading one type of portability for another: rather than relying on the way your compiler handles UB directly, you are relying on the way your compiler does some ID (implementation defined) behavior: if you run your code on a different compiler, or a different version of the current compiler, the ID could change completely and the unexpected result probably quickly leads to either UB or some functional bug anyways.
That said, I think defining things as implementation-defined is only really useful when you have specific feature-check macros you can use to determine the behavior.
Otherwise you are kind of just trading one type of portability for another: rather than relying on the way your compiler handles UB directly, you are relying on the way your compiler does some ID (implementation defined) behavior: if you run your code on a different compiler, or a different version of the current compiler, the ID could change completely and the unexpected result probably quickly leads to either UB or some functional bug anyways.