The bug trackers are also a fine place to provide community feedback. For example there's plenty of comments providing use cases that weren't hidden. But if you read the hidden ones (especially on the issue rather than PR) there's some truly unhinged commentary that rightly resulted in being hidden and unfortunately locking of the thread.

Ultimately the way the community can influence decisions is to not be completely unhinged.

Like someone else said the other way would be to just use XSLT in the first place.

For a new browser engine adding some of the new APIs is pretty trivial compared to debugging all the nonsense that comes from these kinds of underspecified legacy APIs. Removing XSLT from the spec and existing browsers means new ones don't feel the need to implement it. They don't need to decide which implementation to go with (use libxslt like chromium and webkit and you might match their behaviour but you also get all the same security vulns).

Frankly a modern engine could probably get by without handling XML entirely (aka no XHTML document support) and get by just fine but that's a separate discussion.

Third-party cookies are now heavily restricted and while not quite removed everywhere cannot be relied upon.

document.domain is no longer settable by default in Chromium, and other browsers are aligned on matching this.

There's other APIs that have been restricted to secure contexts only.

The list goes on and on, the idea that the web is this unbreakable surface isn't true. It does break things and that is a good thing, if you want the platform to succeed for decades to come they should be able to fix mistakes.