Thinking you can label the churn as something it’s possible to avoid by single choice upfront about dependencies is not realistic enough to be useful. Churn is not just about the dependencies- but also about the project ...

Projects which are updated often have a forcing function on them - they need to become updateable ... that can mean tests, that can mean reasonable build tools, and that can mean dropping individual dependencies that are too painful to update.

Obviously some ecosystems make all these things easier than others — typed languages with reasonable consistent build processes help more than anything. Good codebases that isolate and wrap usage of most dependencies next and reasonable automated tests probably next most useful.

It is definitely the case that some codebases are easier to update than others even given the same ecosystem/dependencies. When is the pain of “churn” most reasonably considered my fault instead of yours? Those are the situations can be fixed and they can get you pretty far — much further than “ahh, this codebase has javascript and webpack i shall rewrite with make and closure” can get you on average ...