n-D means "more than two but less than five". What you're seeing is some leakage from the programming side to the user side. When "more than two" index support was built, I built it generically, so it could handle arbitrary extra dimensions. As a result, all the internal functions end up having "nd" in their signatures, and that thinking leaked out into the documentation.
However, since the PostGIS data model only supports objects of up to 4 dimensions the "n-D" code never gets used with more than 4 dimensions. Also, some of the implementation code around the edges uses "no more than 4" as a simplifying assumption, so truly using the code as "n-D" would take some clean up and verification.
Because it's possible to have both indexes on the same geometry (you can build both a 2d and an nd index on a geometry column) we also needed distinct operators so the user could choose which kind of filtering to apply: hence, && as 2-d overlap and &&& as n-d overlap, as well as the other "more symbols please" operators outlined in the other answer.
One thing potentially under appreciated about higher dimensionality is the freedom you have to encode what you want in those higher dimensions. 'Z' has kind of an agreed meaning, but the 'M' dimension is usable for anything at all. So X/Y/Time data can be both stored (in a POINT M () or a LINESTRING M () for instance) and indexed using the n-d index. High-speed multi-dimensional searching in a unified space/time domain. Sounds good, right?