The "error tolerance" introduces algorithmic complexity into what could be a parsing problem.
Root cause: DOM parsing can lead to a different result when you take the first-pass output, serialize it to HTML again, and use it as input for the second parsing pass. And if it sounds stupid: browser do this, AFAIK.
Side note, not security-related: CSS has introduced two-pass rendering since Flexbox, AFAIK. Not the same thing regarding what "rendering" means (there, it's about boxes on screen, not about transforming HTML->HTML, but...).
Lehacy inline attributes that allow JS execution are a favorite example, but disabling them via CSP is not a silver bullet.
Even if you disallow all attributes like "onclick", "onload", etc, modern document parsing is not context-free, and allows for arbitrarily complex exploits, AFAIK (a href, src or style payload can be just as bad as arbitrary JS execution).
The author of the ancient library DOMPurify made a decent amount of money from explaining this thoroughly and providing solutions.
In short, detecting XSS is a variant of the Halting Problem in some especially hard cases, as far as I remember. Because HTML parsing is not context-feee.