C'est une excellente remarque. Je pense qu'il y a une combinaison d'au moins trois facteurs.

Premièrement quand on commence à écrire une application c'est relativement facile d'écrire du code qui fonctionne sans trop se soucier de ce qui viendra après. Mais chaque mauvais choix, même petit, risque de coûter exponentiellement de plus en plus cher (= de plus en plus de temps à contourner) à mesure que le projet progresse. Quand on finit par prendre la décision de le corriger, à supposer qu'on la prenne un jour, on risque de devoir y passer plusieurs ordres de grandeur de fois plus de temps que si on avait fait en sorte de l'éviter initialement. Mais comme d'une part c'est plus difficile et que d'autre part on a l'impression qu'on perd du temps alors qu'on pourrait commencer tout de suite, on prend souvent la mauvaise solution.

Deuxièmement l'informatique est une science immature pour laquelle il n'y a pas vraiment de bonne façon de faire universellement acceptée. Ou bien on pourrait dire qu'il y en a plein, ça revient au même. Beaucoup de gourous ont tout un tas de théories sur les bonnes pratiques à suivre pour que tel ou tel projet se passe bien, mais ces théories sont trop jeunes, incompatibles, et noyées dans une masse d'informations contradictoires. En cherchant 3 minutes sur Google à peu près n'importe quelle sujet informatique on trouve des dizaines d'articles rédigés par des experts auto-proclamés et c'est un peu difficile de s'y retrouver. Ça n'est pas vrai que pour les projets personnels, loin de là.

Troisièmement il y a eu une explosion de la demande de développeurs, et du coup une explosion de l'offre de formation pour ces métiers. Aujourd'hui on forme des informaticiens à la pelle (enfin il parait qu'il y a toujours une pénurie, mais elle va bien finir par s'arrêter et ça risque d'être douloureux) et forcément tous ne sont pas aussi efficaces. Quand on combine ça avec le point précédent, comment fait-on pour reconnaître un bon développeur ou un mauvais développeur ? Si on les interroge séparément ils auront tous une vision bien trempée de comment leur boulot "devrait être fait" et un avis tranché sur le niveau de leurs collègues exactement à l'image des réponses de ce sujet sur les "stagiaires" qui semble-t-il sont responsables de tous ces projets qui foirent (à croire qu'il n'y a que des stagiaires dans cette branche, je me demande ce qu'ils deviennent une fois diplômés). En pratique peu importe qui a raison, il suffit d'avoir plusieurs personnes qui ont un avis incompatible sur la façon dont le travail devrait être fait (ce qui veut dire souvent "avoir plusieurs développeurs sur le projet") pour que tout se coince.

Du coup on a des boites qui annoncent pouvoir mettre des armées de gens sur des projets, puis des projets qui prennent des tournures catastrophiques au bout de quelques années, les mêmes boites qui essaient de remédier au problème en mettant encore plus de gens sur le projet (puisque logiquement plus on ajoute de gens plus ça avance vite, "9 femmes font un bébé en 1 mois" et compagnie), et ça tourne en boucle joyeusement. Des projets publics assurés par des "boites technologies françaises" j'en ai vu quelques-uns et le schéma est le même à chaque fois, ce que décrit ce mec dans son article est malheureusement aussi triste que commun.