Most PRs I reject with "this should be a patch sent to the list" simply because I'm not always the only one that should review something.
Yeah, well, maybe that's a bad idea?
There is another big FOSS project I know which has its own bug tracker from way back when (horribly outdated, frequently malfunctioning, terrible usability) and then they have their new GitHub tracker. The result? If you want to file anything, you have to file it in both systems.
What I'm trying to say is: You have to make a choice at some point. Either you move forward and solve problems, or you stay where you are. But don't blame the move forward for not allowing you to stay where you are.
Even if I'm wrong, comments on pull requests are certainly notifications for everyone who is watching the repo.
Watching is if you actually want to pay attention to activity as opposed to just bookmark something.
With PRs on GitHub, a corresponding issue is usually filed and if people still email you, simply tell them to first search there and then post their own. That way, everybody can see and search the existing stack quickly.
I recently tried to contribute to a project that maintains both a mailman mailing list (I offer a thousand internets to somebody who builds a general purpose and usable UI to that) and a GitHub tracker and it was an absolute nightmare to coordinate.