When people talk about maintenance burden they aren't talking about your scenario. A codebase where you walk away for 7 years and then come back? That's something people can do now for any project in any language. When people talk about maintenance burden they're talking about what tomorrow to the next few years is going to feel like for people who actively maintain projects.

So when you're actively maintaining something and you bring in a dependency, you're in some sense outsourcing some of that work, whether it's a colleague or an outside party maintaining that library. The specifics of who begins to matter. Is it the React team maintaining that part of the codebase? Is it lonely author in Kyiv? Or is it you?

So what is it like to be the colleague of someone who wrote their own Tanstack Forms and successfully or unsuccessfully integrated with Zod and the like? Or did they choose to write their own runtime type validator too? That's maintenance burden.

Active is a relative term. The modern frontend monoculture is built for a high churn codebase. Sure, seven years is extreme, but even for two years, there will be more issues if the cold project that I'm trying to load was made with the modern, npm-based frontend monoculture versus if it was all custom code.