Moreover, such organizations are made up of their members, and it's up to the members to do the right thing as well. Nobody had to volunteer to be the first to add this gunk to their browser. It can't be a competitive disadvantage if nobody else has it either, and it can't be a competitive advantage if everybody else has it, and those are the two options so why not choose the first?
As much as some people like to say one is better than the other, I think the answer is always "it depends". Unfortunately, it depends not only on the relative power and momentum behind the current problem when deciding, but also on unknowns such as what will happen in the future.
It's hard for me to find too much fault in them deciding that they would rather stay somewhat relevant to the process than become obviously irrelevant (if that was indeed the thought process), as there's still a lot they can affect in the future. Armchair quarterbacking about what they should have done isn't too useful in my eyes.
The downside is as you say that the browsers can point to the standard as for why they implemented it, but that's why it's a trade off, and not cut and dry (IMO)
The DRM module would still ship with Chrome and Edge (and likely Safari too, given Apple became involved pretty quickly), you'd still need multiple different streaming formats (in the form of different DRM formats) as you do today, and maybe you'd need slightly different JS codepath per-browser too (but that's not a big difference to today with the different DRM formats).
It's very unclear to me that the W3C refusing to be involved from day one would've led to any outcome very more than subtly different than the one we ended at. At the point that the specification went to Recommendation, there were already multiple interoperable implementations, so objecting at that point was purely a matter of principle, it literally wouldn't have affected the outcome in any way.