Como outros observaram nos comentários, uma razão óbvia para exigir permissões de root é que os pacotes pré-compilados são instalados em diretórios compartilhados do sistema, que não devem ser gravados por qualquer pessoa. Por que não "um usuário não root diferente"? Eu diria, porque pacotes suficientes precisam fazer mudanças em diretórios e arquivos compartilhados do sistema que não valem a complexidade de saber quais pacotes realmente precisam de root e quais não, e porque não instalar como root não compra todos muito - você já está colocando sua fé no fornecedor para muitos dos pacotes principais, então o que há de mais. Mas, em última análise, sim, há um trade-off de segurança e parece que os fornecedores decidiram que a simplicidade ganha aqui.
Isso nos leva à questão de por que os pacotes não podem ser instalados apenas para, digamos, o diretório pessoal de um usuário. Na verdade, em muitos casos, eles podem, mas apenas se você usar uma distribuição baseada em fonte, como o Gentoo. Nesse caso, você apenas compila o programa com um argumento --prefix apropriado ou similar (muitos, mas não todos, componentes de software suportam tal conceito). A maioria das distros é baseada em binários e, nesse caso, o problema é que muitos programas Unix são escritos de tal forma que vários caminhos são codificados no programa em tempo de compilação, e uma tonelada de trabalho e coordenação seria necessária. para mudar isso quando você está lidando com milhares de pacotes e seus mantenedores. A coordenação é especialmente difícil no mundo Unix, já que existem relativamente muitos fornecedores de sistemas, ao contrário do Windows, onde a Microsoft pode ditar mudanças em grande medida - e até mesmo a Microsoft tem problemas para fazer com que todos entrem na fila, daí a necessidade de medidas de compatibilidade como Virtualização do UAC .
Indo mais para o problema do caminho codificado, considere um programa foo que precisa acessar algum tipo de banco de dados. Onde está esse arquivo? Um caminho plausível é /usr/share/foo/foo.db , que seria codificado no programa, para que ele saiba exatamente onde procurar. Você pode objetar que um programa poderia simplesmente tentar $HOME/usr/share/foo/foo.db ou similar se não encontrar seu arquivo codificado. Isso é verdade, e isso seria bom, exceto que não existe um padrão ou uma convenção real para esse tipo de coisa, então a maioria dos programas simplesmente não implementa esse mecanismo de fallback (esse problema de coordenação, novamente). E, sem dúvida, também adiciona complexidade que beneficia uma parte relativamente pequena da população de usuários, mas isso é outra lata de worms.
Um problema relacionado é como um programa carrega as bibliotecas compartilhadas das quais depende. O vinculador dinâmico, ld.so , precisa saber onde encontrar todas essas bibliotecas compartilhadas. Basicamente, uma lista de caminhos pode ser (novamente) codificada no executável em tempo de compilação, caso em que ld.so pesquisará esses caminhos primeiro; Caso contrário, ld.so pesquisará os diretórios configurados em /etc/ld.so.conf . Esse problema é relativamente fácil de superar, por exemplo, definindo a variável de ambiente LD_LIBRARY_PATH apropriadamente.
Assim, a conclusão é que muitos programas não são projetados para serem flexíveis (em tempo de execução) sobre como eles localizam seus arquivos e, conseqüentemente, os desenvolvedores de pacotes não acham que vale a pena oferecer a opção de instalando em diretórios alternativos. Não é que isso seja tecnicamente impossível - apenas que até agora, não houve a vontade de criar um padrão e fazer com que todos o seguissem. Para um exemplo mostrando como isso não é tecnicamente impossível, você pode dar uma olhada na minha resposta para essa pergunta: Instale o git no servidor sem sudo . Note como é uma solução feia, e esse é o triste estado das coisas.
Para registro, eu realmente compartilho sua frustração por não poder instalar facilmente pacotes binários em locais alternativos, e passei tempo e esforço consideráveis ao longo dos anos na compilação manual de pacotes ou trabalhando em torno de problemas de empacotamento (de maneiras semelhante à questão a que me vinculei no parágrafo anterior) ao executar em sistemas onde os administradores de sistema não são cooperativos sobre a instalação de pacotes que eu quero usar.