See https://github.com/w3c/web-platform-tests/pull/5172. Test at https://w3c-test.org/submissions/5172/encoding/textdecoder-copy.any.html and https://w3c-test.org/submissions/5172/encoding/textdecoder-copy.any.worker.html for now (until that PR lands).
This seems like it may be performance sensitive. What's the rationale?
This has been the behavior since the API was introduced. We did introduce a flag ignoreBOM that makes it not stripped.
There's many UTF-8 entry points in the platform that strip a leading BOM, so offering that functionality seems very reasonable and since you know about whether or not it needs to happen when TextDecoder is constructed, it should not necessarily be performance-sensitive I think, but you might want to branch during decode for convenience, which shouldn't be too costly.