Le alternative a CentOS procedono: Rocky Linux lancia la prima release candidate, AlmaLinux dispone del supporto a pagamento

Certamente c'è anche questo scenario, come ce ne sono tanti altri, es non c'è budget, chi paga il rifacimento della macchina?
Oppure il setup è il frutto di anni di lavoro, patch su patch custom rilasciate dal supporto di [metti multinazionale big IT a caso] a seguito di ticker sanguinosi e niente di tutto questo è documentato.
Oppure non ci sono più gli installer o non vi si ha accesso perchè nessuno ha rinnovato la tal subscription, etc etc.

Insomma gli scenari sono tanti, quella che descrivi se vogliamo è la migliore delle ipotesi, no moneta no cammello, e di certo se sei pagato per fare manutenzione ordinaria o presidio non regali un setup da zero, quello giustamente te lo fai pagare e bene.

Capiamoci, non ho detto che ne sono entusiasta, però non ci vedo nemmeno questa tragedia epocale.
Anche a me è capitato di avere qualche problema per un update (l'ultima volta credo sia successo un paio di anni fa per un update di php, rollback immediato, dopo poche ore c'era già una fix, fantascienza anche per il prodotto commerciale più avanzato e strapagato) però oggettivamente dalla mia esperienza sono casi veramente rari.

Sullo scenario che descrivi riguardo ai container io onestamente non sono così ottimista, non lo vedo così rosa e fiori, anzitutto perchè aggiornare un container non è a costo zero (in termini di effort) o quantomeno è largamente superiore rispetto all'uso di un package manager schedulato.
In secondo luogo dalla mia esperienza anche la riproducibilità di un servizio che gira dentro un container non è sempre garantita, a me ne sono capitati parecchi di scenari in cui due ambienti, con gli stessi container, stessa versione di docker (o altro servizio simile), stessi parametri (o file yaml nel caso di docker-compose), si comportano in modo diverso e tocca tutte le volte ritoccare qualcosa.
Sul rollback nella gran parte dei casi cambia poco o nulla rispetto ad uno scenario tradizionale, per il semplice fatto che tolte le applicazioni totalmente stateless (che nel mondo reale sono più una teoria che realtà, perchè 9 volte su 10 qualche repository ce l'hai sempre, che sia un db o un volume persistente) in molti casi aggiornare un sw (aggiornando il container sulla base di una immagine con una nuove versione del prodotto) significa toccare qualcosa anche sul repository dove stanno i dati, sia che si tratti di qualche ddl per aggiornare la struttura del db o qualche modifica alla struttura dei file.

Ok però oggettivamente trovami qualcuno che avendo a disposizione un repository yum o apt si mette a ricompilare da sorgenti.
La ricompilazione la facevo ai tempi di RedHat 7 (la prima, non RHEL), a meno di avere esigenze talmente specifiche da non essere soddisfatte dai binari disponibili sui repo trovo veramente difficile che qualcuno si metta a ricompilare.
E questo per mille motivi, anzitutto per una questione di costi, ripetere il tutto ad ogni aggiornamento poi diventa ingestibile, e francamente rispetto a un sw che si aggiorna manualmente ogni morte di papa preferisco un repo conosciuto, anche se non certificato o che abbia un controllo di qualità di livello RedHat.

Per fare un esempio che credo molti abbiano sperimentato, in ambito RHEL e derivate praticamente EPEL è un repository necessario, è impensabile lavorare senza e francamente da quando è disponibile non ho trovato una singola macchina RHEL o CentOS che non l'avesse usato, non solo, spesso si trovano specifiche indicazioni di installarlo anche in prodotti enterprise per soddisfare dipendenze.
Vogliamo parlare della qualità dei binari distribuiti tramite Epel? Alcuni sono talmente obsoleti da essere imbarazzanti, sulla stabilità di altri ci sarebbe molto da discutere.

O prendiamo php, volente o nolente praticamente chiunque usa Remi repo, io trovo che il lavoro che c'è dietro sia ammirevole, e di una qualità in termini di supporto che veramente bagna il naso a multinazionali multimiliardarie, però non si può certo dire che sia all'altezza di standard di livello RHEL o Ubuntu LTS in termini di solidità, in fin dei conti è un tizio (che tra l'altro mi pare lavori in RedHat) che nel tempo libero fa tutto questo.

Non lo metto in dubbio, però capiamoci, sono casi un po' diversi.
Un conto se parliamo di un sistema operativo installato ora, su una distribuzione attuale, con aggiornamenti attivi e costanti, servizi che ci girano sopra le cui dipendenze sono costantemente aggiornate, etc etc...
Altra cosa se parliamo di macchine mai aggiornate per anni, dove chiaramente lanciare un apt upgrade o yum update sarebbe cosa davvero azzardata.

Ben inteso, ne ho viste tante anch'io in quello stato, però non è un problema dell'os instabile, ma di un percorso di upgrade che non è stato seguito.
Ma lo stesso l'ho visto su Windows, mai aggiornati per anni e dove il cluster active/passive scoppia.

Come ti dicevo io da anni ho deciso di applicare la politica "updates no matter what" e francamente di problemi ne avrò avuti un paio in anni e anni e presso tanti clienti e tanti scenari diversi; e non parlo solo di updates ufficiali di Rhel o della vecchia CentOS, ma anche di package installati con Epel, remi, rpmforge e altri.

Chiaramente non saprò mai quali problemi però ho evitato aggiornando sempre e comunque tutte le notti, soprattutto dal pdv della sicurezza.
Di certo c'è però che se si verifica un disguido per un package appena aggiornato è ovviamente spiacevole, ma se si verifica un problema per obsolescenza dei package o perchè non si aggiorna (e di solito lo vieni a scoprire a cose fatte perchè c'è una buona probabilità che si tratti di un problema di sicurezza) la situazione è decisamente più grave; i miei clienti tendono a essere moooolto più accondiscendenti nel primo caso, e giustamente molto meno nel secondo.

Riassumendo, rispetto al tua esperienza e concordo con te che lo scenario ideale sarebbe usare distribuzioni a prova di bomba (RHEL, Ubuntu LTS o Debian stable) però dal pdv tecnico non ci vedo tutto questo "casus belli", eticamente invece è un altro discorso e sono d'accordo al 100% con la polemica nata dopo le recenti decisioni di RedHat