> I'd argue that it's not exactly "better", but more that it just makes different tradeoffs.
Yes, it makes tradeoffs that are different, and those tradeoffs are different in that they're better. Often, not always. That's the statement in a nutshell.
> Using a full well-written* dependency for something not part of your "core competency" (even something seemingly trivial) is often a better choice in my opinion.
If it's outside your core competency, you can't really judge if a dependency is well-written. Popularity is an entirely unreliable quality metric. "Well-tested" also means nothing, a lot of people write completely useless unit tests but still fail on integration. How much time are you going to spend researching and vetting the code and the development "team" for that "seemingly trivial" dependency? How about writing a few lines of code and building a little bit of understanding instead? You can still use other people's code as a reference, even copy parts of it.
> That dependency will often know the "unknown unknowns" to you since their "whole purpose" is solving that one issue.
Sure, a few lines of code may have unknown unknowns. You know what else has? Other developers. Unbeknownst to you, "the team" could be the left-pad guy, who turns out to be "political". "The team" could be the guy that just hands over an unmaintained repository to a cryto-thief from China. That one took several weeks to get noticed by the community.
You start with one little dependency for one use-case, you end up with hundreds if not thousands of dependencies. You realistically have no capacity to deal with this in a diligent manner.
One could argue that by using "modern Javascript" with its pathological reliance on micro-dependencies, one has already given up control to the hive of random developers anyway, so one more dependency wouldn't hurt. I probably would agree with that. That doesn't mean every Javascript program would be better off this way.