basically, my rule of thumb is that i have to be prepared to take over and maintain any dependency that i use. it's all part of my code. if i am not prepared to do that then i better avoid pulling in the dependency in the first place.
the leftpad example, as it happened, was not a maintainer issue. had the maintainer just stopped working on it, replacing leftpad would have been a no brainer for anyone taking their project seriously. deleting leftpad was deliberate sabotage by the maintainer, even if he may not have predicted the consequences.
i dare say that the leftpad incident would not have affected me because i never deploy live depending on remote resources. everything needed to deploy is cached, and the only time leftpad disappearance would have affected me is when setting up a new project, at which point the failure to build would be an oops, there is a bug, we need to fix it kind of situation.
i don't rely on others such that if they don't do their work my house would come crashing down. if that happens, then that's on me. i rely on things that have been proven to be stable. a maintainer disappearing does not affect the current stability of any of my systems. it only affects future upgrades, and i can deal with those.
even security issues don't necessarily depend on the maintainer such that only the maintainer could fix them. that's the whole point of FOSS, that anyone can fix issues if necessary. in the worst case someone out there would work on a patch to fix the log4j issue, or, remove it as a dependency. if the issue is critical enough for me, then that someone might even be myself.