Not suggesting an alternative model here, but I think that Google et. al (based on my own time working on Chrome) don't take that responsibility quite as seriously as they should. Being responsible may be an accident, but being dominant in any given area is not. The forces inside Google which take over parts of the world do so without really caring about the long term commitment.
It is so possible to preserve XSLT and other web features e.g. by wrapping them in built-in (potentially even standardized) polyfills, but that kind of work isn't incentivized over new features and big flashy refactors.
Completely agree. Among the reasons I no longer work for Google is that I could not escape the perception that they were the 800-lb gorilla in the room and deeply uncomfortable with taking on any responsibiliy given that circumstance.
When you are the biggest organization in a space, it's your space whether you feel qualified to lead or not. The right course of action is "get qualified, fast." The top-level leadership did not strike me as willing to shoulder that responsibility.
My personal preferred outcome to address the security concerns with XSLT would probably be to replace the native implementation with a JavaScript-sandboxed implementation in-browser. This wouldn't solve all issues (such an implementation would almost certainly be operating in a privileged state, so there would still be security concerns), but it would take all the "this library is living at a layer that does direct unchecked memory manipulation, with all the consequences therein" off the table. There is, still, a case to be made perhaps that if you're already doing that, the next logical step is to make the whole feature optional by jettisoning the sandboxed implementation into a JavaScript library.
It is so possible to preserve XSLT and other web features e.g. by wrapping them in built-in (potentially even standardized) polyfills, but that kind of work isn't incentivized over new features and big flashy refactors.