You should not assume that U2F makes you 'immune' to most types of phishing.
If your assumption is that users will fall for phishing tests then it follows that they will present their U2F token or simply take some action on behalf of the attacker directly.
The point of U2F is that they can't do that. For example, if I send you a fake Google login page, you can't "trick" me into entering my token - it won't work.
Yeah, if you'll read that blog post it'll explain exactly that.
U2F tokens are a second factor for authentication, meaning that to log into your account you need your password and the token.
Further, the token takes the domain into account when it's generating the key. That means that you can't just give me a fake Twitter page and then forward the creds/token, it won't be valid.
U2F mitigates this entire class of phishing attack.
Beyond that, we also only allow logins to sensitive services from employee laptops, validated by a TPM, and multiple other controls, but that's not really the point.
> Or 'I'm on vacation and left my laptop, could you just run this command on the prod cluster for me so we can avoid downtime over the holidays?'
Right, so this would work, but it's a huge gap between "Hey run this command for me" and the attacker being able to run arbitrary commands. It's a reasonable thing for your security team to consider and attempt to mitigate in other ways.
If your assumption is that users will fall for phishing tests then it follows that they will present their U2F token or simply take some action on behalf of the attacker directly.