It seems to me that at least latent in your suggestions is the assumption that the RFC Editor should publish only IETF consensus documents or documents that are in general agreement with IETF consensus.
Actually, my assumption is that only documents for which there is a significant supporting constituency should be considered for publication as RFCs. So for instance, if a different well-recognized standards body wants to publish something as an RFC, I don't have a problem with that, as long as it's clearly labeled as being from that standards body. Or if a WG specification doesn't manage to meet the requirements for standards track but the WG wants to publish that specification as an Informational RFC, as a record of the work that was done in case the problems can be solved in the future, I don't have a problem with that either, as long as it's clearly marked and the identified problems are also mentioned in the document.
What I have a problem with is individuals demanding the right to have their half-baked specifications published as RFCs, and for the RFC Editor to publish those documents as RFCs without public review, or (as has happened in the past) even when substantial oversights or design flaws in those specifications have been pointed out to the RFC Editor.
My sense is almost exactly the opposite. The IESG is not omniscient and wouldn't be omniscient even if they had a lot more time. The IETF isn't omniscient either.
Nor, for that matter, is the RFC Editor. But IESG is IMHO much more likely to catch problems in an individual submission than the RFC Editor. And unlike RFC Editor decisions, IESG decisions can be appealed.
IMO, one of the most valuable types of documents the RFC Editor could publish would be an independent, in-depth analysis of why some standards-track document was an operational hazard and generally a complete crock of excrement. Now I would expect that a very high editorial and technical standard would be applied to the arguments of such a document. I would expect it to be excruciatingly clear that the positions it was taking were in disagreement with an IETF Standards-Track procedure. But I would hope it would be publishable, and, given those document quality standards, published, even if every single member of the IESG disagreed with its stated position.
I don't have an inherent problem with that either. However I haven't seen any defined "very high editorial and technical standard" for such documents, which makes me wonder if this amounts to the whim of the RFC Editor. I think we're long past the day when any two or three people, no matter how intelligent or experienced, can profess to understand Internet protocols in enough breadth to be the sole judge of what should merit publication on behalf of IETF. And like it or not, if there is no other well-identified supporting consistency for an RFC, it's assumed by the public to have IETF backing.
Clearly-stated dissent is not "harmful". Indeed, I suggest that it is healthy. And the procedure you propose would tend to suppress such dissent, no matter how well reasoned that dissent was.
Clearly-stated dissent is not harmful. But inflating it to appear to have equal or near-equal standing with community consensus can be misleading.
I can think of a number of topics for which I'd like to get on a soap box and have my "clearly-stated dissent" published as RFCs: scoped addressing, encoding routing policy in address bits, and autoconfiguration systems being a few of the "interesting" and timely topics that come to mind. However I don't think I have the right to demand that the RFC Editor provide, and ISOC fund, a soap box that appears to give my personal opinion near-equal weight to the consensus of IETF. And I don't think it scales very well.
OTOH, I would certainly like to see a process that allowed "well-supported minority opinions" to get some recognition.
Instead, we use the notion of "rough consensus" to essentially run over dissent by small minorities, even small minority dissent that is well-reasoned and has significant merit. And our appeals is useless in dealing with that issue because the "rough consensus" really does exist. And that makes the ability for the dissenters to write a dissent, and have it published in near proximity to the official/standard specification, really important to preserving the openness and honesty of the system. Without it, all sorts of theories about cabals become very plausible.
Now we haven't used that mechanism very much. In my personal opinion, we haven't used it nearly often enough -- especially in the last several years, the losing dissenters have tended to just go away rather than documenting their positions --but that is another issue. But taking it away, which I think your suggestion would ultimately do, could ultimately be extremely harmful to our standardization model.
My opinion is that if we're going to pretend to have such a mechanism, we need to actually define it - establish publication criteria and the procedure for requesting publication and set up a vetting process that can hope to scale. I don't think saying "whatever the RFC Editor wants" is a good way to do this.
Keith