Fammi un esempio di "portabilità" migliorata da una cosa del genere.
Così come manutenibilità.
Perchè è esattamente il contrario
Allora, qui stiamo andando su una flame war, ed io non ho alcun interesse a portarla avanti.
Secondo te è meglio un unico file da 30+K righe? Ognuno fa quello che meglio crede.
Tu parli di ragioni storiche che non hanno più senso, ed è vero fino ad un certo punto: gestire file lunghi non è mai stato un problema su alcuni sistemi, mentre la suddivisione in più file è di provenienza più accademica che altro: la maggior parte dei libri/corsi divide i progetti d'esempio su più file perché è più semplice stampare e commentare un file corto che un malloppo da 5Krighe.
Però un file unico non è la soluzione unica ed imprescindibile: se devi modificare qualcosa per adattarlo od aggiornarlo, devi picconare... esattamente come farebbe uno che ha diviso il progetto in più file.
Ho lavorato in ambienti industriali dove si preferiva "1 file.c == 1 processo". Poi aprivi il file per modificare qualcosa e ti trovavi davanti a decine di cose del tipo:
#ifdef __AIX_4__
...
#ifdef IMPIANTO_DI_XXXX
...
#elseif IMPIANTO_DI_YYYY
...
#endif
....
Per cui capire se stavi guardando il codice in esecuzione o delle ramificazioni morte o non usate in quel contesto era cosa non immediata. Certo, era molto portabile: bastava aggiungere un altro #define ... nel makefile e ricompilare fino a far sparire tutti gli errori. Se dopo la compilazione ed il linking "stava su", eri a posto!
Migliorare il codice in questi casi non è sempre possibile (né fattibile, neanche in casi di revamping), se avessero optato per una struttura diversa avrebbero risolto qualche problema ma ne avrebbero introdotti altri.
Se a te (e a Google) piacciono i file grandi, sei libero di fare come credi. Io non ti impongo niente. L'op può fare come crede. Se non ha vincoli progettuali, può fare un solo file. Se il committente gli chiede 2+ file, deve farne almeno 2.