Which is just the issue... pointer arithmetic that lands outside the bounds of an array is undefined behavior. I'm not going to argue that this makes 99% of all programs ill-formed (with haphazard results) because every pointer arithmetic bears a result that is outside the bounds of some array (and given the fact that there is argv, there is always at least one other array).
... what? not some array, the array that is involved in the pointer arithmetic expression! And while that specific part of the standard seems arbitrary in light of the modern, unified, fully byte-addressable memory model of today's architectures, it makes more sense when you view it in the context of segmented memory architectures, where in C you still only have, say, an int* pointer type, but you could have two int arrays in two different memory segments, and it's just not possible to meaningfully, say, subtract the two array pointers, or add an integer to one array to reach the other somehow; with this in mind it makes sense to not have distinct arrays be able to interact in any way (not that most code does this anyway)
EDIT: I think I see your misunderstanding now; the standard states that a pointer not otherwise part of an array may be treated as a one-element array in the context of pointer arithmetic (it is actually very clear on that point)
I agree some aspects of undefined behaviour can seem punishing in that a meaning could have been assigned to the operation that everyone would have been happy with and it would have made life much simpler. But, these things were decided upon a long time ago, and in many cases there were historical reasons for why the standard is written a certain way.