I'm of a similar mindset... Docker dev environments are only slightly inconvenient, but much like a full VM, having exactly what you need, and the versions is kind of nice sometimes... especially working on differing projects.
Aside: it's a blessing and a curse how many projects don't get curated/groomed regularly for updates/upgrades. I think it should be a day or two a month to update dependencies and runtimes to current. I've now been on a handful of projects in the past year with versions of resources pinned from 3+ years ago. It's disturbing.
Usually have pretty good test coverage, I've tended to suggest setting aside one day a month to update all project(s) and dependencies, much like Systems Admins will often do the same (more) for system updates.
Most of the time, the updates don't require code changes, so it's maybe an hour, then tests, smoke tests, test/uat pass and release, like any other more significant frequent release ci/cd cycle. About twice a year, it may be deferred for a couple days, if there's a major library update with breaking changes. In those cases, new story(ies) go into the top of the backlog to handle it as a higher pointed change.
Not every environment will follow the above... which is how you see projects with multi-year old dependencies, sometimes 2+ major releases behind. IMO, it should be considered the same as ceremonies and planning, it's just part of the lifecycle. That it doesn't get treated as such is the issue.
Aside: it's a blessing and a curse how many projects don't get curated/groomed regularly for updates/upgrades. I think it should be a day or two a month to update dependencies and runtimes to current. I've now been on a handful of projects in the past year with versions of resources pinned from 3+ years ago. It's disturbing.