So here's the thing: I've been releasing my code as open source for nearly 15 years. When I write something for me, I release it for other people. Inevitably, I eventually stop needing that thing, so I stop spending time on it.
When a PR comes in for a project I haven't actively worked on in a while, handling that PR requires me to reacquaint myself with the old code, remember how and why I made certain choices, consider whether accepting the PR would create any new maintenance burdens for me or would potentially introduce problems for users who've been using a stable and unchanged program for years now. If I decide it's worthwhile, then I have to test it. Maybe my old project has tests; maybe it doesn't. If it doesn't, that means I have to get it running and test manually.
More often than not, a PR will contain questionable code or inconsistent formatting or something else that requires some back and forth with the author. This takes time out of my day (often out of several days due to the async nature of this communication). Even if all goes smoothly and I end up accepting and pulling in the PR, now I have to decide whether to push out a new release. That means updating change history, maybe updating docs, bumping the version, building release packages, tagging them, pushing them, etc.
Some of this process can be automated, but much of it can't be. I have a lot of old projects that aren't popular enough for a new maintainer to step up and take ownership of, but that I don't want to just abandon, since people still use them. If I allow every PR that comes in to interrupt my day and force me through this process, I'll never get anything done. So generally I'll let PRs build up for a little while until I have a chunk of free time, and then I'll sweep through and deal with them all at once. Sometimes this takes months or even a year or two.
The beauty of open source -- and especially open source on GitHub -- is that none of this matters. If there's an outstanding PR on one of my projects that you want to use, you can fork the project and pull it into your fork. You have exactly as much control over the code as I do, and I use very permissive licenses for exactly this reason.
If something is important enough for someone to want me to spend my time on it but not important enough for them to spend their time on it, then it's generally not urgent, and I'm not going to allow myself to feel guilty about it. Otherwise, open source would be no fun at all.
My empathy for those maintaining open source is vast. My suggestion to alleviate the pressure is to focus their amazing energy on fewer things.
Software, open or private, is a thing produced by labor. In the open case, community participation should not be limited to passive consumption without critique. Without feedback, how could it improve to the greatest potential?
The open projects that persevere tend to be the main focus of those maintaining them. I am concerned there is entirely too much energy directed at reinvention vs. evolution.