I don't know the actual reason, but one thing I might suggest is that it would allow inconsistent / implementation-detail-dependent comptime code, which is generally something we try to disallow:
if (comptime ptr_a < ptr_b) { ... } else { ... }
It's the same sort of reason that @ptrToInt is disallowed at comptime - comptime pointers are fancy (since they're GC'd and point to boxed values) so you can't meaningfully look at the raw value. In that case, we just disallow the operation at comptime, but it's possible that for comparisons, being a less "explicit" operation in a sense, the core team didn't want to make that distinction.
A simpler argument might be that putting @ptrToInt wherever you need comparisons, while a bit more verbose, is less bug-prone and easier to read since the intent is very explicit and pointer comparisons aren't a hugely common thing to need.
Note that in your case, you could probably just write a small helper function if you want:
fn assertPtrRange(ptr: anytype, min: @TypeOf(ptr), max: @TypeOf(ptr)) void {
if (@ptrToInt(ptr) < @ptrToInt(min) or @ptrToInt(ptr) > @ptrToInt(max)) {
unreachable; // assertion failure
}
}
// assertPtrRange(val, min, max);