These are web APIs, not Android/iOS specific, and IIRC Google and possibly other browser vendors have expressed interest in these APIs.

Web standards require voluntary cooperation and isn't something that can be resolved by allowing "better" standards variants to win in a marketplace over others (otherwise they wouldn't really be standards).

Apple has pre-emptively blocked the standardization of these APIs because they effectively have veto power, and they have veto power because web standards aren't really a free market. Browser vendors choose not to ship standards that major browsers don't all agree on, which means that Apple's singular objection scuttles the process by design.

Of course this is one of the risks you have with standards, one bad actor can screw everything up. It's why standards often suck and it's a happy miracle that the web is as good as it is. When Apple themselves can screw up a standard that they directly compete with (web vs native iOS) from the inside, well, that's just too convenient for them.

This isn’t accurate. There are plenty of instances of browser vendors implementing API’s ahead of other vendors.

It simply isn’t true that vendors always wait for agreement. Apple’s participation is important, but not mandatory.

They implement APIs ahead of other vendors because someone has to do it first and try out an implementation, most standards start out as experimental implementations. But when other major browsers reject it as a standard, the API is usually deprecated.

I'm sure there exist instances of vendors not waiting for agreement, those are rare exceptions because it essentially breaks the standard. Web fragmentation was a big problem for a long time and the major browsers have largely willingly agreed to avoid that. Apple's participation is de facto mandatory, they control a major browser and other major browser vendors won't ship something that Apple has openly declared they will never support.