My thoughts on why invented standards succeed or fail
(By success I mean that the standard is implemented and gets used; by failure I mean that it is either not implemented or ignored.)
Implementing and using a standard has costs, and people are lazy. This implies that a standard's chances of success are going to depend a lot on its benefits relative to the current status quo. Thus, the 'best' (most likely to succeed) invented standard is in a new field (one without existing standards to 'compete' with it) and answers a clear need, solving a problem that people are wrestling with; such a standard delivers high benefits, as it is the only solution to a real problem.
Correspondingly, the 'worst' (least likely to succeed) standard is one that is in a field that already has existing standards (either formal or just de facto) and that offers only minor functional differences over what you can already do with the existing standards. Even if the cost of using this standard is extraordinarily low, its 'profit' (benefits minus costs) will always be small because its benefits are so small; with higher costs of use, you'll never see any net benefit from using it.
(I have sort of been ignoring the costs of implementing and using a standard, but obviously they matter too; an extraordinarily costly standard had better deliver extraordinary benefits, and you can probably get people to adopt a standard that has zero cost but only a small benefit because, well, why not adopt it at that point, it's not like it costs you anything. There are probably ways to reduce the cost of a standard, such as by delivering a test suite as part of it.)
This is by no means the whole story of why standards succeed or die; in real life, as opposed to theoretical musings, there is a whole pile of other things going on. (After all, the ultimate way of getting your standard to succeed is to have it adopted as a requirement by someone who is big and powerful. But as they say: with sufficient thrust even pigs can fly.)
The risk continuum for standardization success
Following on from the three stereotypes of standards approaches: so you have a standard. Now, how likely is it to succeed, or at least to be implemented (since standards more or less necessarily fail if they're never implemented)?
Well, that depends on the specific standard. But we can ask what the continuum of risks is for each stereotype of approaches to standardization.
At one end of the continuum is pure documentation, where the behavior the standard calls for already exists and so the standard is 'implemented' the moment it's written up. Vendors don't need to implement anything, they just need to not change anything that you've documented.
In the middle is coordination; vendors have to implement something, but they've already agreed to do so. And from there to the far end are the various ways you can approach invention, ranging from talking a lot to vendors about what they're happy with (but not requiring explicit agreement to implement before you go ahead with the standard) to basically having no contact with would-be implementors at all.
In addition to the 'will anyone build it' risk, there is also the 'will it actually work once implemented' risk. Documentation has no risk here; you know it works, because it already exists and you presumably wouldn't be standardizing it if it worked badly (yes, I'm an optimist). Coordination has some risk but the vendors should be convinced that it will work before they agree to it, and invention has various levels of risk depending on how you go about inventing the standard.
Well, sort of. The coordination versus invention division breaks down here because in both approaches you need to decide what to specify, and whether the standard is useful has more to do with how you go about making those decisions than what is going on around those decisions. I do think that coordination has somewhat lower risks because the vendors have more riding on the standard working (if it doesn't, they have probably wasted the effort of implementing it), but vendors can make howling mistakes too.
That the pure documentation approach has such low risks of both implementation and usefulness goes a long way to explaining why it has such a high appeal.