I think you may be underestimating how large systems are today and the performance engineering considerations that drive design decisions toward e.g. 32-bit storage and memory addressing types on current servers with locally attached storage measured in petabytes. The metadata for managing data under these constraints starts to seriously pressure RAM.
Locally, this implies only 50-something bits but it also means the virtual memory silicon can no longer be used. Not a big deal, we know how to deal with this. At this scale, we aren't using conventional file systems either, they perform very poorly. Nonetheless, the dozen or so bits left over are often required for other critical addressing metadata that don't use that remaining value range efficiently. A single bit here or there may not seem like much but it forces tradeoffs that cascade through the architecture.
Locally, you want to be able to represent most addressing types as 32-bits, 64-bits at the outside, even though the global addressing is often necessarily 128-bits in large systems. The elided bits are inferred, not stored.
In large data infrastructure systems, we are right up against what 64-bits can naively support, but in implementation 32-bits is used everywhere for good reason. We can mostly fit within 64-bits globally, if we are clever, but that isn't going to last for too much longer. Machines generate incredible numbers of records per second in a way that humans do not.
FWIW, the largest single data models I am aware of are not byte-addressable with a 64-bit integer, signed or unsigned. Fortunately, that is not a problem I have had to solve, but it is a portent of the future. Nonetheless, if you look at the internals of current ultra-scale database kernels, just about everything addressing-wise is intentionally fitted into composites of uint32_t types for performance reasons.