That's a false dichotomy. There are middle grounds which can and do work at scale:
Upgrade knowingly and deliberately (don't just spray greenkeeper everywhere).
Carefully monitor changed application/network behavior after upgrades.
Devote a manageable, non-zero amount of time to reading/finding security bulletins or security incidents on your most-heavily-used dependencies.
Pay attention to issue reports and prioritize any with possible security implications.
...and (at a slightly larger scale) hire, empower, and compensate people to do those kinds of things in a systematic, regular way.
Seriously, security engineering isn't served well by "ZOMG NPM is garbage we must switch to $megaframework and pray that their release engineers get everything right" hysteria and absolutism. There are effective, moderate strategies that help with these issues every day.
1) only upgrade dependencies “knowingly and deliberately” (as the author of this article did). What does this mean if not auditing the upgrades? Just upgrading more rarely (e.g. because you know you need a specific feature or bug fix), but still auditing them? By waiting to upgrade, the diff will be vastly larger and performing an audit to “knowingly” upgrade will be much more difficult.
2) detecting a breach after you’ve already installed an attacker’s code onto your servers, via active monitoring or by hoping someone else does active monitoring or auditing and reports the issue to you or to a central authority.
#1 as a “middle ground” doesn’t seem too different from the post you responded to. #2 is what most projects seem to rely on - hope someone else finds the problem and reports it, and that they don’t get hit too hard in the meantime.
Packaging and distribution of libraries takes effort to do it properly, so they're only done properly if it's sufficiently centralized. If you have to import fifty third-party wheels, then it's unavoidable that some or most of these wheels can't be managed properly, but it's quite feasible to have a single (or three) well-managed third-party package that provides a hundred wheels so that you don't have to reinvent them. If the strong_password gem was integrated in (for example) Rails and managed/released by the same team with the same processes, then this risk would be avoided. If instead of a dozen separate gems with every functionality separate you'd have a single bundle of varied functionality like in Java there's Guava or Appache Commons, then that bundle can handle release management in a way that each separate gem developer can not.
If you want to have reliable dependencies then you eithery have to choose only dependencies with buraucratic and pedantic release governance, or manage/audit each dependency yourself (as the author of the original article seems to have done). In ecosystems where it's reasonable to have serious projects that have 0-3 distinct (but large) external dependencies this works easily; in ecosystems where you have dozens or even a hundred dependencies, that overhead is impractical for most projects.