Well the imagined OffsetArray and AbstractArray would be quite a bit more rigid than they are now. AbstractArrays would always have 1-based axes, and OffsetArray is only a parametric wrapper type to tack on offset indices; they would be orthogonal concepts that dispatch to separate methods and require type conversion to work together, much like the linked docs described. It seems preferable to design the orthogonality in different documented types than in errors thrown by require_one_based_indexing in some heavily nested internal callee method.
There wouldn’t really be room for other concrete offset array types. Definitely a cost of making code for AbstractArray simpler and 1-based, but seems okay at this stage considering we still can’t matrix-multiply OffsetArrays.
It could dispatch to methods intended for very specific offsets, but I also doubt that it’s useful. The examples in the blog post I linked tend to treat offsets more like instance information (different rotations and shifts).