One way to reduce this risk is modularization. If development stops for a single module, it can be replaced quite painlessly compared to rewriting everything because one relied on a monolithic framework.
Yes. The problem is that things like YUI (or Django, or NodeJS, or Rails) are not modules. These are frameworks where you plug your code in, not the other way around. And besides, the dictate the programming paradigm, not just variable names. You cannot create an abstraction layer on top of YUI that would work seamlessly for Angular or jQuery or straight DOM manipulation. They are completely different.
I agree that YUI can be seen like this, with its relatively deep object relationships and manipulations required for its mvc, widgets, etc. -- but does not have to be used as such. I've been using YUI the last couple of years in a lighter way. My code uses as much modern JS as practical, and dips in to YUI for things that are tedious to do by hand. Most of my modules can be swapped out to work with requirejs, jquery, underscore, handlebars, etc. without too much fuss. I've done that a few times when YUI was slowing down and showing signs of neglect, but then went back to YUI because I saw no noticeable signs of improvement, but rather found the code more difficult to maintain -- multiple dependencies vs. 1, and each of those libraries has a multiplicative effect (different documentation locations and styles, following the updates, engaging the community, finding workarounds, etc.) For a long time YUI had great docs, great participation from core devs, and a nurturing attitude towards 3rd party modules. It is when that love began to fade, without explanation -- the promises of improvements in the future began to gather cobwebs, and the community infrastructure began to crumble (forum, gallery, web site), yui dev participation plummeted -- that I and I'm sure many other YUI users began to disengage with the YUI project, even if we were still using it.
What I mean is that YUI is a large, monolithic framework, which can be replaced with a number of smaller libraries/frameworks. This is modularization, which reduces the risk of a large monolithic framework losing maintenance support.