The discussion of standards seems like it unhelpfully conflates the reality of standardisation by bodies like the IETF that have no discernible authority and don't want it even if it were possible - with "de facto" standards which it says are just whatever people do in practice. Not so.
The IETF is not a conventional SDO, nor indeed a conventional organisation of any sort, since it has no members, and it operates on "rough consensus" rather than having some specific formal process that invariably (see Microsoft's interaction with ECMA and ISO) would be gamed by scumbags.
But nevertheless those are de jure standards that come out the far end, the result of "getting all major stakeholders in a room" albeit that room is most often a mailing list since only a hardcore few can attend every IETF physical meeting. The IETF even explicitly marks standards track RFCs distinctly from non-standards track ones. If you contribute documentation for a complete working system, rather than (as Google did with QUIC) a proposal based on such a system that needs further refinement, it'll just get published as an Informational RFC. Such RFCs are how a bunch of Microsoft network protocols are documented, by Microsoft. Whereas months of arguing and back-and-forth technical discussion have shaped the IETF's QUIC and will continue to do so, the documentation for MSCHAPv2 (commonly used in corporate WiFi deployments) is an informational RFC so a Microsoft employee just dumped it as written, no chance for anyone to say "Er, this protocol is stupid, change it not to shove zero bytes into this key labelled C or else anybody can crack user passwords after spoofing the AP". So they didn't, and you can.
To be fair, the parent comment is slightly misleading. I don't know the exact story of MSCHAPv2 but note that it is an informational RFC published by the pppext WG: https://tools.ietf.org/html/rfc2759
For an RFC to be published by a WG, it must first be "adopted" by the group, which means a first draft is submitted by the author, and then debatted (sometimes lightly) until the group agrees that it fits the topic and is suitable for adoption. Similarly, once the RFC is adopted, it goes through a series of calls by the WG chair where people have opportunities to comment, until it is finally published. Informational RFCs have lighter requirements than standard tracks one, so they are easier to get published, but they still get some amount of review and comments before publication.
In fact, even "independent submissions" with "experimental" status (that do not go through a WG at all, https://tools.ietf.org/html/rfc2026#section-4.2.1) get reviewed before publication. The reviews in that case are private, but a RFC editor is responsible for sanity-checking the document and sometimes requests additional input from reviewers specialized in the domain area covered by the draft.
[Edit: the actual WG for MSCHAPv2 was https://tools.ietf.org/wg/pppext/, not "Networking" which is just the generic name on top of the RFC]
Although you're correct that there was a drafting process for MSCHAPv2, the actual protocol it describes had already shipped in Windows. As a result "But this is a bad idea" would not have been a useful contribution to the drafting process, the zero draft describes the exact same protocol, just with different words.
Edited to add:
The drafting process wasn't worthless, it fixed typographical errors, unclear descriptions, and so on. For example the zero draft insists Windows usernames are "Unicode" (UCS-2) but actually they're just ASCII, the examples show ASCII encoded hexadecimal but the text in the zero draft specifically calls it Unicode. And originally the document repeatedly says something is a 16-bit value in the text while showing a 24-bit value in structures, the final RFC has corrected this to split out an 8-bit "reserved" all zero field in the structure when this happens. In at least one place the RFC seems to "extend" the protocol compared to the zero draft, but again this isn't a response to Working Group feedback, it's documenting a patch Microsoft shipped in later Windows versions after the zero draft.
I don't know how much a WG chair could have usefully interfered here. As I say it's documenting something that already existed, so "fixing" it to document a more secure protocol nobody was using wouldn't help. The IETF's role here was to help people interoperate with Microsoft's solution, your non-Windows OS that can sign-in to a corporate WiFi system with Windows domain servers is enabled by this documentation.
The IETF is not a conventional SDO, nor indeed a conventional organisation of any sort, since it has no members, and it operates on "rough consensus" rather than having some specific formal process that invariably (see Microsoft's interaction with ECMA and ISO) would be gamed by scumbags.
But nevertheless those are de jure standards that come out the far end, the result of "getting all major stakeholders in a room" albeit that room is most often a mailing list since only a hardcore few can attend every IETF physical meeting. The IETF even explicitly marks standards track RFCs distinctly from non-standards track ones. If you contribute documentation for a complete working system, rather than (as Google did with QUIC) a proposal based on such a system that needs further refinement, it'll just get published as an Informational RFC. Such RFCs are how a bunch of Microsoft network protocols are documented, by Microsoft. Whereas months of arguing and back-and-forth technical discussion have shaped the IETF's QUIC and will continue to do so, the documentation for MSCHAPv2 (commonly used in corporate WiFi deployments) is an informational RFC so a Microsoft employee just dumped it as written, no chance for anyone to say "Er, this protocol is stupid, change it not to shove zero bytes into this key labelled C or else anybody can crack user passwords after spoofing the AP". So they didn't, and you can.
[Edited: wording tweaks near start, sorry]