> It's fine to disagree on the costs/benefits and where you draw the line on supporting the removal, but fundamentally it's just a cost-benefit question

If browser makers had simply said that maintaining all the web standards was too much work and they were opting to depreciate parts of it, I'd likely still object but I wouldn't be calling it bad faith. As it stands however, they and their defenders continue to cite alleged security problems as one of if not the primary reason to remove XSLT. This alleged security justification is a lie. We know it's a lie because there exists a trivial way to virtually completely remove the security burden presented by XSLT to browser maintainers without depreciating it, and the chrome team is well aware of this option. There is no significant difference in security between "shipping an existing polyfil which implements XSLT from inside the browser's sandbox instead of outside it" and "removing all support for XSLT", so security isn't the reason they're very deliberately choosing the former over the latter.

> This seems overly dramatic. It's a small streamlining of an important software, by removing an expensive feature with almost zero usage

This isn't a counter argument, you've just repeated your point that XSLT (allegedly) isn't sufficiently well used to justify maintaining it, ignoring the fact that said tradeoff being made by browser maintainers in the first place is a problem.