My rationale for staying up to date aggressively is that it minimizes integration work. Basically integration work multiplies, it doesn't just accumulate. So the further you fall behind the more that can break when you finally do upgrade. And you create needlessly more work related to testing and fixing all that. Upgrading a system that was fully up to date until a few days/weeks ago is generally easy. There's only so much that changes. Doing the same to something that was last touched five years ago can be a bit painful. Apis that no longer exist. Components that are no longer supported. Code that no longer compiles. Etc.

I see a lot of teams being overly conservative with keeping their stuff up to date running with years out of date stuff with lots of known & fixed bugs of all varieties, performance issues that have long since been addressed, etc. All in the name of stability.

I treat anything that isn't up to date as technical debt. If an update breaks stuff, I need to know so I can either deal with it or document a work around or a (usually temporary) version rollback. While that happens, it doesn't happen a lot. And I prefer knowing about these things because I've tried it over being ignorant of the breakage because I haven't updated anything in years. It just adds to the hidden pile of technical debt you don't even know you have. Ignorance is not an excuse for not dealing with your technical debt. Or worse compounding it by building on top of it and creating more technical debt in the process.

Dealing with small changes over time is a lot less work than with dealing with a large delta all at once. It's something I've been doing for years. If I work on any of my projects, the first thing I do is update dependencies. Make sure stuff still works (tests). Make sure deprecated APIs are dealt with.