You fork it and take over as the new upstream maintainer ?

The article touches on the security aspect, but doesn't highlight the real tension: if you have a proper build cycle, part of that is automated security scanning with multiple tools. Once an EOLed part of your stack is raising issues, they'll keep getting raised and dismissed with an exception to the rule of "fix all security issues". The backlog of unfixable issues grows, and in places with strict policies about addressing issues, this becomes untenable.

JS microdependency packaging makes this exponentially worse.

I think fork is not solution, you should start over. As software evolves, new features are added rather then removed, complexity grows. This is not a problem for the "old guard" because they entered it when it was simple and gradually became more complex. But new people have to learn the complex version from the start, there is no gentle slope. This i believe is major problem with old software and IMHO the only solution is start over, smaller. Focus on the issues you want the software to solve. Yes the cycle will continue and your software will became complex too but at least it will continue rather than stop or rot.

Also people's expectations are different (lower) when they switching the software than when the software switches the maintainer.

I listened to an episode of Open Source Security Podcast and they talked about making EOL of opensource dependencies a CVE type. I think it bears thought.