Suponha que você esteja trocando dados com um computador em uma porta <1024 e saiba que o computador está executando alguma variante do unix. Então você sabe que o serviço em execução nessa porta é aprovado pelo administrador do sistema: está sendo executado como root ou, pelo menos, teve que ser iniciado como root.
No mundo amplo e selvagem da Internet, isso não importa. A maioria dos servidores é administrada pelas mesmas pessoas que os serviços executados neles; você não confiaria mais nas raízes do que nos outros usuários.
Com máquinas multiusuário, especialmente em uma rede local, isso pode importar. Por exemplo, nos dias antes criptografia civil, um método popular de executar comandos shell em outra máquina foi rsh( r emote sh ell); você poderia usar a autenticação por senha ou autenticar apenas provando que era usuário X na máquina A (com a máquina B sabendo que X @ A poderia efetuar login como X @ B sem senha). Como provar isso? O rshcliente é root setuid e usa um número de porta <1024; portanto, o servidor sabe que o cliente com o qual está falando é confiável e não mentirá sobre qual usuário de A está chamando. Da mesma forma NFS foi projetado para ser transparente com relação aos usuários e permissões; portanto, uma configuração comum era que, em uma rede local, todas as máquinas usavam o mesmo banco de dados do usuário, e o usuário N em A que monta sistemas de arquivos do servidor B obtém as permissões do usuário N em B. Novamente, o fato de o cliente NFS ser proveniente de um número de porta <1024 prova que a raiz de A examinou o cliente NFS, que deve garantir que, se ele transmitir uma solicitação que supostamente seja do usuário N, essa solicitação será realmente do usuário N.
Usuários não autorizados não podem executar servidores em portas baixas é outro benefício, mas não o principal. Naquela época, a falsificação era uma novidade e os usuários que executavam servidores falsificados eram rapidamente reprimidos pelos administradores vigilantes de qualquer maneira.