The argument seems a bit myopic. The author is talking about errors and vulnerabilities found in libraries while ignoring those same factors in bespoke code. At best that's a "security through obscurity" scheme.
The problem with libraries is that they often contain so much functionality while you yourself might only need a single thing (and don't even realise all the stuff the library is able to do). Whenever I had to patch systems due to some vulnerability my first thought was "Wait, why the hell is a <xxx> library even able to do that?"
The log4j2 vulnerability is probably a good example of this. How many systems running log4j2 actually uses the JNDI functionality that led to the exploit?
I'm not sure they are ignoring those factors in their own code. It's more a case that the libraries might be increasing their risk factor by an order of magnitude or more.
Only if you use a small percentage of the functionality. If the dependency is maintained (not all are!) there is a good chance someone else discovered many of the bugs, the the per bugs per line of code metric should be much lower. And the dependency probably has some features you wish existed but can't justify the effort to write.
It is about trade offs. Is the time/money saved and the additional features gained worth the cost that some of features you don't use may result in more bugs that affect you in some way. For the most part I'd say no: I can write my own whatever, but that too will have bugs, and I need to fix all of them. I work with people who disagree with me on this one, and so we have a lot of pain maintaining code we wrote ourselves that isn't as good as a library I could have downloaded. Or in some case code that is already on our system - We have 6 different logging frameworks in one project, 3 we wrote in house, this is a big mess.