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.
Open source isn't about launching products. When I release something I've written, it's not because I want it to win marketshare or something; it's just because I work in the open by default. I write code for myself, and I share it for whoever else finds it useful.
But my needs change, so in time I may stop needing that thing I wrote. If someone else is willing to take over the project, great! But that's rarely the case. So that thing I wrote goes into maintenance mode, and I only touch it occasionally when I have free time, because I want to help the people who are still using it.
When I sit down to write a piece of software that I need, the questions of "should I release this?" or "is this too many spinning plates?" never enter my mind, because it's not a choice. I need something that doesn't exist, so I'm going to write it. I don't just sit around trying to think of ideas for a new open source project to start.
T.J. is one of the most prolific developers out there, and I know what it feels like to send him a PR that he doesn't look at for a long time. But I also know what it feels like from his side of things, so I try not to pressure him about it.
Open source guilt is a real thing that really hurts people emotionally and professionally. People get depressed over it, quit their careers over it, sometimes even contemplate (or commit) suicide over it. It's not worth it. As a community, we need to be more empathetic and supportive of people who volunteer their time and experience for the benefit of others.