1. Even if you don't want to always use the latest dependencies, having the capability in reserve is important. When some emergency need pops up (e.g. massive security issue) you don't want to be trapped by a wall of your own making. So you'll at least need a pattern of prototyping and testing builds with newer dependencies, even if the builds aren't released. (Discover how to make your code forward-compatible before it becomes an emergency.)

2. As a general rule, newer means fewer security vulnerabilities, particularly if the project is careful about introducing new features versus bug-fixes. Not always, and maybe you don't want super-bleeding edge releases, but mostly.

3. I've worked in some areas with bureaucratic or governmental impediments, where you want to avoid things that might trigger re-testing or re-certification. That's a reason not to upgrade much, but it does mean you need to actually read the changelogs etc. and have some sort of process for noticing when something is important enough.

I agree.

Staying up to date is important but not urgent.

What you really don't want is that you don't do it, and one day it becomes urgent (usually for some external reason.)

You don't want to upgrade your networking the day after TLS 1.0 is rejected by that server you interact with. That seldom ends well.

When things are important to do, you should schedule them I as part of the routine. So you might have a twice-yearly event of "get everything up to date". Doing it regularly keeps it manageable, plus you get better at it. The longer the gap, the more work it is, and the more work it will cause.

It is 99% easier to do when your system is working than when it's broken. The phrase "don't fix it if its not broken" is literally the dumbest thing any programmer can tell you. preventing it from breaking is a gazillion times easier than fixing it after it's broken, while everyone around you is screaming.