Suppose you're exchanging data with a computer on a port <1024, and you know that computer is running some variant of unix. Then you know that the service running on that port is approved by the system administrator: it's running as root, or at least had to be started as root.
On the wide, wild world of the Internet, this doesn't matter. Most servers are administered by the same people as the services running on them; you wouldn't trust the roots more than the other users.
With multiuser machines, especially on a local network, this can matter. For example, in the days before civilian cryptography, a popular method of running shell commands on another machine was rsh
(remote shell); you could use password authentication, or you could authenticate just by proving you were user X on machine A (with machine B knowing that X@A could log in as X@B with no password). How to prove that? The rsh
client is setuid root, and uses a port number <1024, so the server knows that the client it's talking to is trustworthy and won't lie as to which user on A is invoking it. Similarly NFS was designed to be transparent with respect to users and permissions, so a common configuration was that on a local network every machine used the same user database, and user N at A mounting filesystems from server B would get the permissions of user N at B. Again, the fact that the NFS client is coming from a port number <1024 proves that root at A has vetted the NFS client, which is supposed to make sure that if it transmits a request purporting to be from user N then that request really is from user N.
Unauthorized users not being able to run servers on low ports is another benefit, but not the main one. Back in the days, spoofing was quite the novelty and users running spoof servers would be quickly quashed by vigilant administrators anyway.
0 - 1023
that are restricted, and ports1024 - 65534
that are not.