I'm not even mentioning the potential split in the community.
As a project maintainer I’ve made the mistake several times of being too permissive with pull requests. Someone comes along with a feature they’re excited to add to my project. I don’t need the feature myself. They exuberantly make a PR, and I eventually merge it. Before long it turns out there’s a bunch of bugs with that feature, and the original author is gone. Do I waste my time fixing their code, for a feature I never wanted and don’t use? Or do I ignore the bugs and let the smell of low quality work waft over my code base?
These days I default to refusing most feature requests, even if they have decent PRs. I write most software for fun, or to scratch an itch. I don’t do it because I want to manage a community. If you want to add features and build a community around a project I’ve written, great. I’m happy to link to your fork in my readme.
Forking is not a symptom of failure. Maintaining a fork is sometimes just the ticket price to control your destiny.
Also the person in question is also a well-received volunteer, which is why this is getting traction to begin with, which is why Rich Hickey would even take the time to tell someone that they aren't worth the time of the very response they're reading.
I think you are misrepresenting what Rich wrote. He said you are not "entitled" to a response. That is not an evaluation of someone's worth, but a statement about what they are owed, or not owed.
Then what?
1) find a work-around (maybe unwind his or her own mess) 2) manage a fork 3) work with the existing process
I've worked around people doing all three of these options but what I've regularly found was that taking a look at unwinding your own mess is the right approach for the vast majority of cases.
Seems to be an ego thing.