Há duas razões principais.
A primeira razão é que, embora as CPUs x86 ofereçam quatro anéis de proteção de memória, a granularidade de proteção oferecida é apenas no nível por segmento. Ou seja, cada segmento pode ser definido para um toque específico ("nível de privilégio") de 0 a 3, juntamente com outras proteções, como desativação de gravação. Mas não há muitos descritores de segmento disponíveis. A maioria dos sistemas operacionais gostaria de ter uma granularidade muito mais fina da proteção de memória. Como ... para páginas individuais.
Portanto, insira a proteção com base nas entradas da tabela de páginas (PTEs). A maioria, se não todos os sistemas operacionais x86 modernos, ignoram mais ou menos o mecanismo de segmentação (na medida do possível) e confiam na proteção baseada em PTE. Isso é especificado pelos bits de flag, que são os 12 bits mais baixos em cada PTE - mais o bit 63 em CPUs que suportam não execução. Há um PTE para cada página, que normalmente é de 4K.
Um desses bits de flag é chamado de bit "privilegiado". Este bit controla se o processador deve ou não estar em um dos níveis "privilegiados" para acessar a página. Os níveis "privilegiados" são PL 0, 1 e 2. Mas é apenas um bit; portanto, no nível de proteção página por página, o número de "modos" disponíveis no que diz respeito à proteção de memória é apenas dois: Uma página pode ser acessível no modo não privilegiado ou não. Daí apenas dois anéis.
Para ter quatro toques possíveis para cada página, eles precisariam ter dois bits de proteção em cada entrada da tabela de páginas, para codificar um dos quatro números possíveis de toques (assim como os descritores de segmento). Eles não.
A segunda razão é o objetivo da portabilidade do SO. Não se trata apenas de x86; O Unix nos ensinou que um sistema operacional podia ser relativamente portátil para várias arquiteturas de processador, e que isso era uma coisa boa. E alguns processadores suportam apenas dois anéis. Por não depender de vários anéis na arquitetura, os implementadores de sistemas operacionais os tornaram mais portáteis.
Há um terceiro motivo específico para o desenvolvimento do Windows NT. Os designers da NT (David Cutler e sua equipe, que a Microsoft contratou da DEC Western Region Labs) tinham uma vasta experiência anterior no VMS; de fato, Cutler e alguns outros estavam entre os designers originais do VMS. E o processador VAX para o qual o VMS foi projetado (e vice-versa) possui quatro anéis. O VMS usa quatro anéis. (De fato, o VAX possui quatro bits de proteção no PTE, permitindo combinações como "somente leitura no modo de usuário, mas gravável a partir do anel 2 e interno". Mas discordo.)
Mas os componentes executados nos anéis 1 e 2 do VMS (Record Management Services e CLI, respectivamente) foram deixados de fora do design do NT. O anel 2 no VMS realmente não era sobre segurança do sistema operacional, mas sobre a preservação do ambiente da CLI do usuário de um programa para o outro, e o Windows NT simplesmente não tinha esse conceito; a CLI é executada como um processo comum. Quanto ao anel 1 do VMS, o código RMS no anel 1 precisava entrar no anel 0 com bastante frequência e as transições de anel são caras. Acabou sendo muito mais eficiente ir apenas para o anel 0 e terminar com ele, em vez de ter muitas transições de anel 0 dentro do código do anel 1. (Novamente - não que o NT tenha algo como o RMS de qualquer maneira.)
Mas por que eles estão lá, então? Quanto ao motivo pelo qual o x86 implementou quatro anéis, enquanto os sistemas operacionais não os usavam - você está falando de sistemas operacionais com design muito mais recente que o x86. Muitos dos recursos de "programação do sistema" do x86 foram projetados muito antes da implementação do NT ou do verdadeiro kernel do Unix, e eles realmente não sabiam o que os sistemas operacionais usariam. (Somente quando recebemos a paginação no x86 - que não apareceu até o 80386 - é possível implementar kernels verdadeiros do tipo Unix ou VMS sem repensar o gerenciamento de memória desde o início).
Não apenas os sistemas operacionais x86 modernos ignoram amplamente a segmentação (eles apenas configuram os segmentos C, D e S com endereço base 0 e tamanho de 4 GB; os segmentos F e G às vezes são usados para apontar para as principais estruturas de dados do sistema operacional), mas também ignora amplamente coisas como "segmentos de estado de tarefa". O mecanismo TSS foi claramente projetado para a alternância de contexto de encadeamento, mas acaba tendo muitos efeitos colaterais; portanto, os sistemas operacionais x86 modernos fazem isso "manualmente". O único momento em que o x86 NT altera as tarefas de hardware, por exemplo, é para algumas condições verdadeiramente excepcionais, como uma exceção de falha dupla.
Re x64, muitos desses recursos desativados foram deixados de fora. (Para seu crédito, a AMD conversou com as equipes de kernel do SO e perguntou o que eles precisavam do x86, o que eles não precisavam ou não queriam e o que eles gostariam de adicionar.) Os segmentos no x64 existem apenas no que pode ser chamado forma vestigial, a troca de estado de tarefa não existe etc. E os sistemas operacionais continuam usando apenas dois toques.