Très simplement, pendant une grande partie de l'histoire de *nix, il n'y avait pas d'autre choix. Les programmes étaient distribués sous forme d'archives source et la seule façon de les utiliser était de les compiler à partir des sources. Ce n'est donc pas tant une mentalité qu'un mal nécessaire.
Cela dit, il y a de très bonnes raisons de compiler soi-même des choses puisqu'elles seront ensuite compilées spécifiquement pour votre matériel, vous pouvez choisir les options à activer ou non et vous pouvez donc vous retrouver avec un exécutable bien réglé, comme vous l'aimez . Cependant, cela n'a évidemment de sens que pour les utilisateurs experts et non pour les personnes qui souhaitent simplement qu'une machine en état de marche lise leurs e-mails.
Maintenant, dans le monde Linux, les principales distributions se sont toutes éloignées de cela il y a de nombreuses années. Vous avez très, très rarement besoin de compiler quoi que ce soit vous-même ces jours-ci, à moins que vous n'utilisiez une distribution spécialement conçue pour les personnes qui aiment faire cela comme Gentoo. Pour la grande majorité des distributions, cependant, votre utilisateur moyen n'aura jamais besoin de compiler quoi que ce soit puisque pratiquement tout ce dont il aura besoin est présent et compilé dans les référentiels de sa distribution.
Donc, cette mentalité CIY comme vous l'appelez a pratiquement disparu. Il est peut-être encore vivant dans le monde UNIX, je n'en ai aucune expérience, mais sous Linux, si vous utilisez une distribution populaire avec un référentiel décent, vous n'aurez presque jamais besoin de compiler quoi que ce soit vous-même.
Il y a quelques causes à cette mentalité, des utilisateurs finaux, des responsables de la distribution et des fournisseurs de code/développeurs/groupes de projet, et chacune d'entre elles est parfaitement valable.
L'aspect Open Source
Certains aiment savoir qu'ils utilisent des logiciels libres et le valident en choisissant de compiler à partir des sources. C'est là qu'interviennent des choses comme le projet/tuto/guide/livre Linux From Scratch.
L'aspect optimisation et options
Vous voulez compiler des éléments avec des optimisations spécifiques pour votre architecture CPU particulière ? Il existe peut-être une option de compilation (ou un correctif pour en créer une) pour activer ou désactiver une fonctionnalité particulière dont vous avez besoin. Des exemples de cela pourraient être de corriger postfix pour avoir la capacité de gérer les quotas, ou d'utiliser une distribution comme Gentoo où vous pouvez choisir de ne pas utiliser systemd, ou vous choisissez spécifiquement de prendre en charge ogg/theora/vorbis/whatever et PAS mp3 en raison de problèmes de licence ou autre.
L'aspect de l'architecture du processeur
Votre lieu de travail utilise-t-il des machines haut de gamme non x86/amd64 ? Le paquet dont vous avez besoin/que vous voulez peut ne pas être disponible pré-compilé pour votre architecture CPU, et encore moins quelle que soit la distribution que vous utilisez. Certes, la plupart des endroits exécutant ce type de matériel sont également pris en charge par IBM, etc. et n'installent pas / ne compilent pas de choses bon gré mal gré. Mais que se passe-t-il si vous en récupérez un dans une vente excédentaire, déterrez un vieil iMac avec processeur PPC, etc. ?
L'aspect Distribution
Les "familles" de distribution - c'est-à-dire Debian avec Ubuntu, Mint, et al et RedHat avec CentOS, Whitebox, Fedora, et al - utilisent toutes des formats de paquets différents. Et chaque version est livrée avec différentes versions de bibliothèque, etc. Même pour un simple script shell à fichier unique, la configuration d'un fichier Debian .deb approprié prend du temps et des efforts. Si vous avez écrit un logiciel pour gratter quelques démangeaisons, et que vous vouliez le rendre gratuit et le publier sur gitlab, votre propre serveur Web, peu importe, préférez-vous simplement publier un fichier générique .tar.gz de source avec des instructions sur la construction ou préférez-vous empaqueter des versions pour 2 versions de Debian (stable et testing, peut-être oldstable), plusieurs versions de Redhat et Fedora en tant que RPM, un TGZ pour Slackware, un profil ebuild pour Gentoo, etc. etc. etc.
Comme le dit @terdon, de nos jours, le besoin de compiler des choses est assez mince, en particulier pour les utilisateurs à domicile.
Dans le passé, dans le monde Unix, j'étais fortement dépendant de la compilation des sources, par exemple, car je gérais des systèmes Solaris, AIX, Ultrix, Digital Ultrix et HP/UX qui parfois n'étaient plus maintenus par l'éditeur, ou dont les implémentations des services communs étaient loin derrière ce qui était couramment utilisé par d'autres Unix, y compris Linux.
Il existe encore de réels besoins pour compiler des choses dans le présent, soit pour obtenir un logiciel plus obscur ou obsolète qui n'est pas dans les référentiels, soit pour utiliser une version plus récente d'un paquet pour lequel vous n'avez pas de binaires compatibles, ou lorsque vous souhaitez ajouter des fonctionnalités supplémentaires ou rarement, si vous êtes capable d'écrire un patch ou un module pour cela.
J'ai également dû compiler des logiciels à la main lors de la réingénierie de systèmes pour le portage sur Debian et/ou de nouvelles versions de Debian qui avaient un framework qui n'était plus pris en charge par le système d'exploitation.
Par exemple, dans le passé, je devais compiler à la main des démons DHCP pour prendre en charge les modifications (alors récentes) de Windows apportées au protocole, ou pour prendre en charge des correctifs spécifiques pour le provisionnement dans le monde des télécommunications.
Je garde toujours dans mon référentiel local debs pour les versions de FreeRadius compilées par moi-même à partir du référentiel dev git, car il y avait une série de versions stables qui avaient des bogues (graves) dans Debian, et généralement les .debs correspondants pour Debian/Ubuntu n'ont pas été adapté à nos besoins.
Et il va sans dire que souvent, de temps en temps, nous devons aussi exécuter/ou compiler des choses écrites par nous-mêmes.
L'installation des dépendances de nos jours n'est pas aussi difficile que par le passé, et certains logiciels ont même des fichiers de règles personnalisés pour certaines distributions Linux courantes qui nomment les dépendances à compiler et effectuent le lourd travail de création du fichier de package avec la liste des dépendances intégrées. L'installation d'un tel package à partir d'un référentiel local n'est pas très différente de l'installation du même package à partir des référentiels officiels.