Let’s be clear that the security model here is different to that of browser content. You can modify any user agent to disable security measures if you have access to the browser binary, not limited to whether a WebDriver-controlled browser sends a specific header.
I can see a potential use case that websites want to prevent remote controlled browsers from crawling their website, but giving them a header is comparable to UA string sniffing, which websites already do to gate certain browsers from accessing content. Dedicated users spoof the UA string to circumvent this, both for pleasure and automation.
Giving a UA under automation a header would ensure the UA string remained unchanged, potentially letting websites trigger an ‘automation mode setting’ but still trigger the UA sniffing behaviour.
In any case, I’m not sure this is desirable to give websites another mechanism for sniffing the client, potentially fragmenting the web further. On the other side, because it’s impossible to prevent a user modifying the UA, maybe an automation header would be useful if only for convenience.
However, the use cases listed here so far are not convincing: If sending automation tools could avoid CAPTCHAs and ads by sending a header, what would prevent users from modifying their own browsers to do the same? I think the only safe option for triggering ‘test mode’ behaviour on your website is to spin it up an instrumented version in a controlled test environment.