We've heard the same arguments from lazy unskilled devs for decades:
Don't reinvent the wheel.
Premature optimization is the root of all evil.
Writing your own software is not invented here (NIH) syndrome.
The truth is that most software (before AI!) is trash and needed to be "reinvented". This is obvious now with all the vulnerabilities and bugs being discovered. It turns out not all bugs are shallow when the source code is millions of lines.
Since the late 1970's there has been a race to computerize everything. Why? Because it was overwhelmingly advantageous. Imagine owning a business and sending typewriter dictated messages by physical mail when your competitors are communicating by email. Imagine having people update physical spreadsheets by hand and having to make physical copies while your competitors go digital. If you didn't incorporate computers into your business your business would be dead.
This growth meant industry needed software developers faster than they could be produced. Hiring from a small subset of mathemeticians at universities would never be enough. So computer science degrees were created, but that wasn't enough. The appetite became voracious.
By the 2010s the market was so desparate for programmers that companies were hiring people off the street who had gone to 2 week bootcamps. Two weeks and suddenly people are pushing to production. Do you think those people were skilled? Absolutely not!
If you had to literally pull people off the street and have them push code to production what would you tell them? You would probably give them aphorisms to minimize the amount of damage they can do. "Don't reinvent the wheel, just use libraries!" "Don't design anything, just use this framework!" "Dont' repeat yourself!" "If it works, don't fix it!"
All the "good advice" you give them would be essentially "don't write code"! This of course, is reasonable, since these people don't have knowledge or skill. But what happens when you do that for 30+ years? Those juniors you pulled off the street are now senior staff engineers. All the aphorisms you taught them to minimize the damage they do are now "best practices".
This is a disaster. You can't have an industry of only amateurs. But that is what we have. For every expert who has deep knowledge of the field, there's maybe 10,000 developers who are amateur at best if we're being honest.
What does this have to do with tiny code? Well if you have a population of amateur programmers you get junk code. There grows a culture of fear. "Don't touch the code that works, just build on top and around it."
What you get is just heaps of code, with no architecture or design. No one can ever read and understand all the code, so it grows into the millions and billions of lines. You end up creating ever convoluted ways of dealing with monstrously large and complicated code bases. Containers, obsessive testing (full coverage!), CI/CD, frameworks. All of these tactics are trying to cope with the fact that software gets larger and more complicated forever.
Software should be tiny. Any one project should be able to be read and understood by one person -- even an operating system. Dependencies should be minimal. The code should be terse, straighforward, and well designed. The build script should be a single line of bash, no make, cmake, ninja, gradle, etc. No package managers downloading the entire internet to deploy and application. No containers building an entire operating system environment to run a single program. The application should be self-contained; drop it on a computer/server and it works.
The only way to create good software is by using the guidlines above. Those are the real best practices. We need to be ruthlessly cutting lines of code everywhere.
We are now living in a world where billions of lines will be slopped out. If we want to have any chance of quality at all we now have to be ruthless about software quality. We need to hold ourselves to a higher standard and stop hiding behind "best practices" which are actually the worst practices.