Not at all true. As an example, HTML emails may contain <style>, and any webmail client will want to render that, and they’ll definitely want to sanitise the HTML.
Fastmail uses DOMPurify for this purpose, augmenting it with rewriting the selectors in style blocks in order to scope them safely.
(Fastmail also sponsors the DOMPurify bug bounty—I presume the latest mXSS listed at https://www.fastmail.com/about/bugbounty/ corresponds to this thing, and as noted, this issue didn’t affect Fastmail; the reason for that is that Fastmail uses the DOM that DOMPurify returns, rather than problematic and less efficient serialising and deserialising approach.)
And this is hardly the only justifiable reason for allowing <style>. A couple of other examples that occur to me are platforms allowing full user-generated and -styled pages, and validation tools.
Remember with this that each application can choose what it wants to allow or deny. It would be very harmful for DOMPurify to not allow certain sorts of tags just because you can’t immediately think up a reason why you might want to use it.
Fastmail uses DOMPurify for this purpose, augmenting it with rewriting the selectors in style blocks in order to scope them safely.
(Fastmail also sponsors the DOMPurify bug bounty—I presume the latest mXSS listed at https://www.fastmail.com/about/bugbounty/ corresponds to this thing, and as noted, this issue didn’t affect Fastmail; the reason for that is that Fastmail uses the DOM that DOMPurify returns, rather than problematic and less efficient serialising and deserialising approach.)