One possible reason: it makes little sense for 1 << 33 to be less than 1 << 31 but not zero (assuming 32-bit ints -- replace 31 and 33 with 63 and 65 for 64-bit ints). In other words, if you keep shifting a number to the left, it should keep growing, until all the bits are gone.
Another possible reason: CPUs have instructions for implementing << as it now stands.
On x86, the shift instruction only looks at the bottom 5 bits of the shift distance. x<<32 effectively is interpreted as x<<0. (I'm sure other architectures have the same restriction.)
In fact the answer was 5 bits for 32bit and 7 bits for 64bit[1]. x86-64 uses 5 bits for 32bit and for 64bit (shld/shrd can't shift more than 31 bits).
7 bits is problematic because some code may assume that x << -y is an optimization for x << (32-y). I thought there was some architecture where this assumption didn't work on 32bit either, which led to my post above.
Ah, I see... 'Shift' doesn't mean what I thought it meant. Somehow I thought that a left shift was supposed to rotate the number. E.g. shifting by 1 would shift the 31st bit into the 0th bit.
Another possible reason: CPUs have instructions for implementing << as it now stands.