The whole document is good, but in particular, my favorite part (that I reference not infrequently in conversations) is the priority of constituencies:
> In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.
But when designing a standard, if you ignore the needs of implementers you can accidentally write yourself into a place where it becomes impossible for new implementers to completely implement the spec, so we're locked to our existing implementations.
I don't think that HTML has this problem so much, but it's absolutely an issue with both CSS and JavaScript.
It's probably right in this context, but I'd be careful with the last part in general contexts: assuming utility is linear makes for easy reasoning but also would say that a mild stomach ache for every single human (i.e. 7*10⁹ stomach aches) is worth more than the life of someone.
This sounds tricky: since users depend on authors, both depend on implementors, and so on, issues and unhappiness may easily propagate from authors to users, from implementors to both those, etc; similarly to building a project with increasing tech debt, but at multiple layers. And then there is the question of application of this approach: whether one should consider picky and advanced users, or clueless ones, diverse users or an approximated average user, and likewise further along the chain, which is likely to lead to different results.
> In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.