An analogous situation exists in ELF: You can code
- An ELF32 i386 object
- An ELF64 i386 object
- An ELF32 AMD64 object
- An ELF64 AMD64 object
Now, the second of these is useless, since there is no 64-bit i386. The first of these is traditional i386 32-bit code.
The fourth of these is of course the "normal" 64-bit AMD64 code. And the third of these is
x32. 32-bit pointers, AMD64 instructions.
This is not unusual: The same combinations exist for ARM AArch32/AArch64; you can encode an ELF32.ARM, an ELF32.AArch64, and an ELF64.AArch64, which correspond to traditional ARM AArch32, AArch64 ILP32 and AArch64 ILP64. Some architectures, like MIPS, are different: the 64-bit architecture is a straight and strict superset of the 32-bit architecture. There there is no separate architecture code for MIPS64, and therefore no special "MIPS64 ILP32" ABI could be defined, but such an ABI would be superfluous anyway.
You could envisage similar in a PE file. Of course, PE is primarily the executable format of Windows (and secondarily of UEFI), and Windows does not presently support ILP32 ABIs, so such use is not defined.