If this is what I think it is, I consider it very lopsided view, failure to recognize what model fits for what case and looking at everything from a hammer point of view
Of course it's just my opinion.
(Many small dependencies can be avoided by letting the LLM just re-implememt the desired behavior; ~ with tradeoffs, of course)
The issue is orchestrating this local reuse into a coherent global codebase.
You didn't park your car in your driveway so anyone could take it to get groceries
All of these difficulties you outline are because program designs cater to the human developer experience over the machine.
If this weren't the case Python wouldn't exist because it's clearly not made with mechanical sympathy in mind. Dynamic languages as a whole would probably not exist.
It's because humans will never agree with eachother or with machines and that's what has led us to the proliferation of complexity and lack of reuse we see everywhere.
The whole history of programming tool is exploring how to properly reuse code: are functions or objects the fundamental unit of reuse? is diamond inheritance okay? should a language have an official package management? build system? should C++ std have network support? how about gui support? should editors implement their own parsers or rely on language server? And none of these questions has a clear answer after thousands if not millions of smart people attempted. (well perhaps except the function vs object one)
Electron is the ultimate effort of code reuse: we reuse the tens of thousands of human-years invested to make a markup-based render engine that covers 99% of use case. And everyone complains about it, the author of OP article included.
LLM-coding is not code reuse. It's more like throwing hands up and admitting humans are yet not smart enough to properly reuse code except for some well-defined low level cases like compiling C into different ISA. And I'm all for that.