The question is what happens if the programmer doesn't do that. If you are implementing a compiler, what do you do in that case? Are you using whatever is the first or last byte in memory (depending on the machine endianess)? Are you wrapping the value around to keep it consistent between implementations? Are you generating code that aborts the program?

Similar question is also about pointers, what happens if you try to use p^ when p is nil? Do you try to access whatever address nil represents? Do you abort?

C has the notion of undefined behavior and it is explicitly mentioned, but Oberon-07 doesn't mention this at all meaning that implementations need to make those decisions.

If you are implementing a compiler you do what makes most sense for the target language/machine. On the other hand, if you specify exactly how each ill-defined operation should be handled you

1. restrict the freedom of compiler writers. On very small systems, for instance, array bound checking may not be implemented,

2. make programmer rely on non-obvious behaviour/results which makes programs harder to understand and maintain,

3. make the language specification more complicated.

Or you can simply type "Integer to byte conversion and nil dereference are machine dependent" (or implementation dependent if you prefer, but the point is to have something).