Por que os gerenciadores de pacotes são predominantes? Porque as pessoas não gostam de ter que baixar a fonte para cada programa que desejam executar, a fonte de todas as dependências (tempo de compilação e tempo de execução) e compilar tudo sozinha (o que geralmente envolve diferenças nas configurações e remendando o próprio código para funcionar corretamente com as versões específicas dos outros pacotes que você possui. É muito melhor quando alguém compilou o programa para você, suas dependências de tempo de execução, e o gerenciador de pacotes descobre o que precisa fazer o download e instalar para você.
Outra maneira de olhar a partir de uma posição mais centrada no Windows é pensar em "dll hell". No Windows, você faz o download do programa A e usa a biblioteca Z. O instalador do programa A coloca uma cópia da biblioteca Z no diretório do sistema. Você então faz o download do programa B, que também usa a biblioteca Z, mas uma versão ligeiramente diferente. Ele substitui a cópia da biblioteca Z no diretório do sistema por sua versão. Mas essa versão não funciona com o programa A, por isso quebra. Eliminar esse tipo de quebra, assim como eliminar a necessidade de ambos os programas incluírem uma cópia (seja ela compatível ou não) é o que os gerenciadores de pacotes fazem. Eles descobrem quais bibliotecas cada programa precisa e instalam a (s) versão (ões) correta (s), substituindo as mais antigas quando são compatíveis e instalando ambas, se não forem.
A maioria dos softwares do Windows tem a abordagem de apenas incluir a biblioteca Z com ambos os programas e instalá-lo em seu próprio diretório privado. Isso interrompe a quebra, mas significa que baixar os dois programas requer fazer o download da mesma biblioteca duas vezes e ocupar mais espaço em disco e mais memória RAM, pois eles não estão compartilhando a biblioteca, o que anula o objetivo original de ter a biblioteca comum na biblioteca. primeiro lugar.