There are other fingerprinting issues on the web, sure, but this is not one of them. The knee-jerk "all changes on the web are bad" responses are not helpful.
So what use does this serve? Another fingerprinting vector to narrow down browser versions, or worse -- a security hole.
When the "Web Audio API" was rolled out by the Chrome team not only was it fundamentally flawed, but it also contained memory leak CVEs.
Every time they add more trash to the browser nobody asks for (except their ad clients), they introduce more security problems.
So -- why are they adding more APIs when they could fix the old ones that are utterly broken and abused daily by the ad industry? $$$.
Having a builtin XSS sanatizer means it could always use a single parser to prevent such bypass.
This API exposes zero new fingerprinting bits.
Meanwhile userspace solutions for the same solution are a) occasionally buggy b) not as widely used as they should be c) not as performant as they could be if implemented directly within the browser and d) not automatically updated as new browser features are released. Standardizing this will improve all of that.
It is valuable to standardize APIs and build them into the web for features like this where there's a clearly correct approach that's required by a large percentage of modern sites (anything with client side dynamic content). Having browser vendors implement this, embedded in the browser itself and supported by browser implementers directly, is a free security win for the web.