As a library maintainer, closing and empathetically conveying why a pull request is not a net benefit to the project is an order of magnitude more effort than what it takes to throw up not-well-motivated pull requests on someone else's project.
I think a more generalized version of OP's concept goes into a lot of things.
I thought about this when I first played Minecraft on a multiplayer server where people had vandalized the world. Much harder to keep it tidy than making it ugly. I think they usually solved this by giving mods ability to rewind. Crude but effective.
Like, what makes Wikipedia work? It's easy to go back in the version history when somebody breaks stuff?
It looks like there should be a bunch of tricks that could be used to design these systems so that doing the right thing is easier than breaking stuff.
Refusing a suggestion doesn't prompt for a full explanation, it also doesn't mean it won't ever be reconsidered potentially.
People who engage in open source contributions are usually aware of this, the fact that they generally can fork and use their own "improvement" for themselves is usually enough, and the people who feel entitled to get their code merged in your repository are usually not the kind of regular contributors you want to keep around in my experience.
It's relatively easy to merge code in, but takes much more effort and thought to remove the code later. Especially once other things are dependant on it...