Those limits don't come from Debian or from Linux, they come from the hardware. Different architectures (processor and memory bus) have different limitations.
On current x86-64 PC processors, the MMU allows 48 bits of virtual address space. That means that the address space is limited to 256TB. With one bit to distinguish kernel addresses from userland addresses, that leaves 128TB for a process's address space.
On current x86-64 processors, physical addresses can use up to 48 bits, which means you can have up to 256TB. The limit has progressively risen since the amd64 architecture was introduced (from 40 bits if I recall correctly). Each bit of address space costs some wiring and decoding logic (which makes the processor more expensive, slower and hotter), so hardware manufacturers have an incentive to keep the size down.
Linux only allows physical addresses to go up to 2^46 (so you can only have up to 64TB) because it allows the physical memory to be entirely mapped in kernel space. Remember that there are 48 bits of address space; one bit for kernel/user leaves 47 bits for the kernel address space. Half of that at most addresses physical memory directly, and the other half allows the kernel to map whatever it needs. (Linux can cope with physical memory that can't be mapped in full at the same time, but that introduces additional complexity, so it's only done on platforms where it's require, such as x86-32 with PAE and armv7 with LPAE.)
It's useful for virtual memory to be larger than physical memory for several reasons:
- It lets the kernel map the whole physical memory, and have space left for virtual mappins.
- In addition to mappings of physical memory, there are mappings of swap, of files and of device drivers.
- It's useful to have unmapped memory in places: guard pages to catch buffer overflows, large unmapped zones due to ASLR, etc.