This can be used to defeat Content Security Policy, if you have that enabled.
If there were an actual XSS vulnerability in your web application, an attacker might add something like
<script>window.location = 'https://some-phishing-site.example.com';</script>. Without Content Security Policy blocking unsafe inline scripts this would work, but with a proper Content Security Policy this would be blocked by browsers.
<script src="/.well-known/acme-challenge/window.location%20%3D%20%27https%3A%2F%2Fsome-phishing-site.example.com%2F%27%3B%2F%2Fx"></script> and defeat that security measure.
text/plain due to historical reasons.)
Now, you have to use Content Security Policy for this to even be an issue, and even if you do it’s minor in the grand scheme of things, but comprehensive security scanners are right to point out reflection of user input like this even if it is sanitized.