As origens e características de design são diferentes. Em geral, é uma idéia melhor criar um protocolo a partir do zero, porque você pode torná-lo especificamente adequado para o que você precisa, sem ter problemas com protocolos herdados.
Acredito que essa escolha ocorreu porque a implementação no kernel dos soquetes de domínio do UNIX é muito diferente para permitir a portabilidade sadia para a comunicação do kernel do usuário. A lista de protocolos para AF_NETLINK é projetada especificamente para fornecer controle semelhante a ioctl. AF_UNIX nem usa o argumento "protocol" para a função socket . E se eles de alguma forma estenderem a definição para permitir protocolos adicionais, provavelmente quebrariam os aplicativos existentes, e seria muito difícil no kernel redirecionar os novos protocolos para o código de controle do kernel. Também pode ser um risco de segurança sobrepor essas duas funcionalidades (especialmente porque AF_UNIX não foi originalmente projetado com isso em mente).
E por último ... os soquetes de domínio UNIX usam o sistema de arquivos como um namespace (embora haja um hack que permita soquetes "anônimos"). Como tal, eles estão imediatamente disponíveis para todos os usuários que têm permissões para este socket - para se comunicar com o kernel, seria necessário haver um "arquivo" sempre aberto em algum lugar no sistema de arquivos (provavelmente?) Que os usuários usariam para conectar ao kernel.
Em suma, eles são simplesmente destinados a serem usados para coisas diferentes. Mesmo se você puder reutilizar AF_NETLINK para dois processos de espaço do usuário (é feito de forma diferente do que em AF_UNIX), o oposto não funcionaria realmente.