Das ist auch gut so, würde man versuchen das Rad neu zu erfinden gäbe es sicherlich deutlich mehr Sicherheitslecks.
Als Javaprogrammierer sag ich dazu mal: Meistens wohl eher nein. Das Rad sollte viel öfter mal neu erfunden werden, denn Traktorreifen an einem Fahrrad mögen zwar funktionieren, sind aber nicht sonderlich sinnvoll. Der Trend, ein Framework/eine Bibliothek zu nutzen, das/die viel mehr Funktionalität bietet, als das Projekt eigentlich benötigt, verschwendet nicht nur gewaltig Ressourcen, sondern baut auch Sicherheitslücken da ein, wo sonst garantiert keine auftauchen würden. Log4j ist da eigentlich sogar ein super Beispiel für, denn nur die allerwenigsten Anwender einer Software mit Log4j dürften die LDAP-Funktionalität von Log4j tatsächlich benötigen. Ich wage mal zu behaupten, dass der Log4j-Sourcecode ungefähr um den Faktor 100 größer ist, als für mindestens 95% aller Nutzer von Log4j nötig wäre. Dass das das Risiko von unentdeckten Sicherheitslücken deutlich vergrößert, dürfte wohl klar sein.
Dass eierlegende Wollmilchsäue wie Log4j kleine, maßgeschneiderte Lösungen verdrängen, ist in erster Linie nur dem Umstand geschuldet, dass Programmierern oft (oder in der Wirtschaft eher fast immer) nicht die Zeit für ein Projekt zugebilligt wird, die nötig wäre, um ein wirklich gutes Produkt zu erstellen. Das Narrativ vom "Neuerfinden des Rades" ist da nur eine willkommene Ausrede, immer wieder das gleiche Riesenframework zu nutzen, weil schlicht die Zeit fehlt, sich in individuellere Lösungen einzuarbeiten.
Damit will ich natürlich nicht sagen, dass Standardbibliotheken an sich nicht gut wären. Klar muss man nicht jedes kleine Rädchen neu erfinden. Aber für die konkrete Anwendung völlig unnütz aufgeblähte Bibliotheken bringen mehr Probleme mit sich als sie vermeiden.
Frohe Weihnachten! 
