Why do we need an "ILP32" ABI for 64-bit MIPS?
"ILP32" describes an ABI where the
long and pointer types are 32-bit quantities. o32 is already an ILP32 ABI, but n32 is an ILP32 ABI which exploits real 64-bit hardware and instructions (so
long long is a hardware-supported type). In the same notation, n64 is an I32LP64 ABI.
Many programs which had been reasonably portable between 32-bit architectures have bugs when moved away from ILP32. Most of these bugs probably aren't terribly deep or difficult, but there are thousands of programs, and many of them have no need of 64-bit pointers. Linux is very careful to decouple the kernel and application ABIs, and you can run o32 applications on a 64-bit Linux kernel - so it's arguable that you don't need to invent such a thing: if an application really needs 64-bit instructions, recompile it for the n64-like I32LP64 universe.
In the workstation/server world this almost always made sense, the main reason to want 64-bit applications was for more address space. In the embedded world, there is significant demand for 64-bits just for the larger registers.
Dumping n32 would make life easier, but keeping it seems kinder, particularly to those whose OS' are less willing than is Linux to support two different universes.