The issue of cooldowns aside (which is about delaying updates, not reducing their frequency): you're going to have the same set of problems when you update, whether you do it frequently or infrequently. The difference is that if you update frequently, you'll have a smaller set of updates (so it's easier to debug) and you'll have more opportunity to report issues upstream and fix them in a timely fashion.
It's the same underlying problem as CI and build time. Most people abandoned the concept of projects that take so long to build you can only do testing once a week, because CI that runs on every PR provides a much better experience. This is the same lesson applied to updates.
There’s no right answer. Every case is different, trying to impose a single rule for everyone just simplifies things beyond what is reasonable.
That's never a problem until it suddenly is. Company is put at significant risk (courts want to reason by analogy and "engineers skipped maintenance and endangered people" is an easy one) and nobody is to blame since nobody owned the task.
There’s always someone who doesn’t want to take the advice of all the people who’ve been burned because “well it’s never happened to me.” I used to be that someone myself. Until the day it happened to me.
Every week or so there's a new High+ "vulnerability" that gets published against our dependencies and I have to go look at it to confirm that it's yet another case of "it's possible for someone to give this dev-only tool a bad regex that would cause the test runner to OOM on that branch".
The actual split is on which environments the dependency exists in and who can control inputs in those environments. For most private companies who aren't running CI on an open source repo, the dev/prod split is the operative one that determines what you can safely ignore.
The reality is that each update is its own potential security issue and with supply chain attacks being all too frequent, it's not a panacea.
Even beyond security issues: each update is a new opportunity for breakage, not only from bugs in the third-party package, but also from unexpected dependencies on the third-party package's behavior.
"Ya, Windows something ancient had an issue with WevDAV 2 decades ago, but that is not a reason to block the http DELETE verb at the WAF"
This elegantly mitigates three problems in one go: update churn, dependency hell, and supply chain attack surface.
It also, frankly, tends to make the code easier to understand. I’m not a huge NIH person but I do have to say that a lot of packages these days tend to encourage ways of doing things that are unnecessarily complex. More than once I’ve replaced a dependency with homegrown code and reduced LOC in the same commit.