What I would say is that objecting, on its own, is rarely valuable. Whether some Ridley Random on the internet likes or dislikes an RFC isn't really a material input to language decisions.
Here's a couple of common patterns to improve an RFC of which you're not a fan:
-
Provide a missing drawback. For example, the first post in Pre-RFC: Named arguments has an oddly-short drawbacks section. (I didn't check if there's an extended one elsewhere.) Almost every RFC should include the drawback of "this makes things more complicated", which a discussion of why the author considers the extra complexity worth it -- and the more complicated the RFC the more important that section becomes. If there's a drawback that's not acknowledged in the text of the RFC, that's an update that the author should make.
-
Ask for additional rationale. Common questions don't need to be answered in the Guide or Reference sections, but a strong RFC will preemptively answer "Why did this RFC pick _______?" And indeed, figuring out what those common questions are is one of the most useful things that can happen in a pre-RFC phase.
-
Raise other alternatives. The author has some pain point that they're trying to improve. And clearly, that is a pain point to them, so arguing that it's not painful isn't productive. But adding extra alternatives again make the RFC better. That could be "hey, there's this simpler thing that gets most of the good", but it can also be "I don't think this is helpful enough on its own, and should include more", depending on the proposal.
At a meta-level, if you're opposed to something what you want is to get your concerns into the text of the RFC, because that's the best way to either (1) find out that the author has a great answer and you're no longer worried, or (2) make those people who have to make the decision on it go "oh, that really is concerning about this".