I think just about every experienced developer I know - most of whom are not from NZ - would agree with this article. We've all been burned by using the wrong dependency for the job at some point, or the pain of having to deal breaking changes when upgrading a library that really wasn't necessary to use in the first place.
To push back on this article's thrust, those are actual issues that can occur with dependencies. It's just that they usually don't, and most dependencies are harmless, small, and transparent, so articles like this and people complaining about dependencies are almost always overstating their case.
And therefore, adopting a "zero dependencies" policy is absolutely an overreaction.
I'd argue harmless, small and transparent dependencies are the easiest to avoid. The extreme of it "is_even", but any library that could fit in 200 lines should probably be owned code.
Where the article hits is critical libraries that you heavily rely on and that your code is slowly formatted around. I'm thinking specific data parsers, fancy query brokers, time management libraries etc.
I don't think the author is actually arguing for zero dependencies here. While they do quote a "zero dependency policy" in one open source project as being "instructive", they also propose a "framework for evaluating dependencies" - which of course anyone advocating for zero dependencies would have no need for.
