I agree with the core maintainer complaint here: PR slop is bad, and maintainers should not be forced into reviewing code the submitter does not understand.
But I think the answer is not “don’t slop me, all you sloppers.” The better answer is closer to: “what problem were you trying to solve?”
There is no obligation to treat every PR as merge-ready code. A PR can also be a concrete issue report or a proof-of-concept for a bug. It can say: I found a problem, I investigated it, and code was the clearest way to show where I think the issue lives and how it might be addressed. Use or ignore the implementation as you like. Human-language descriptions are not always the best way to communicate something you've already traced through the codebase.
That can be a high-value contribution even if the code itself is not accepted. It moves the conversation from “I want X” to “here is where X touches the codebase, here is a failing case, here is a possible direction, here are the tradeoffs I noticed.”
The social contract should be that the contributor does not dump review debt on the maintainer. Mark it as a prototype. Explain the problem in your own words. Say what you tested. Say what you are unsure about. Be willing to revise or accept that the maintainer may throw the patch away.
But once framed that way, the relevant question is not whether AI was used. It is whether the PR reduces ambiguity or increases burden.
A sloppy PR that demands review is bad. A prototype PR that explains a real problem is often useful.