Autofill of a password manager is a working countermeasure against phishing too: If autofill does not work there is something wrong and you should look closer...
My experience with password managers is that they work great for me, because I understand every sharp edge and can work around them. My experience when advising family to use them is that they invariably fail them and they get frustrated. Password managers rely on pretty gross heuristics to work. They are effectively trying to automate something built for a human (choosing, remembering, and entering a password). WebAuthn gives us a real API built by and for machines. This will make the flow much less error-prone and more secure.
I tend to be a little hesitant to use the browser plugins that do autofill, I think most major vendors have had a vulnerability of some sort at some point. Doesn't mean it's unsafe, it's just the tradeoff I prefer is that I'm more likely to be phished on a single account, but less likely to have my entire DB compromised through a plugin compromise.
Except autofill fails all the time for other reasons. The site has rebranded to a new domain name. They moved the login page or redesigned it. Or it was always badly designed and broke autofill. Or the same credentials are used on multiple domains (think Google, Microsoft).
I can't find a source, but my recollection is that Google developed U2F because autofill didn't work reliably enough, so many users would just paste the password manually anyway.
It doesn't matter whether the technology "works reliably enough" it matters whether the _user_ reliably won't sidestep security by pasting their password in to the phishing site. And that's something we knew the answer to decades ago: No.
Humans are bad at giving up. If there seems to be a way forward for the original plan they will press on, regardless of all indications that this now a bad idea. In fact Google had a security override in Chrome for years that was literally typing the sequence "badidea" in recognition of this. It's not specific to computer security, it happens in incident management, there's a seminal example from years back where a train breaks down, and the incident manager sees that step 1 of the response is to send a recovery train to the location, and literally _hours_ later, with passengers stranded and desperate - that manager was still wrestling with how to get the recovery train to the location so they could proceed to step 2, rather than realising that problems with the recovery train meant they needed to _abandon the entire plan and re-assess_ because humans are not good at that.
Yes and no. Yes, if the attacker controls the DNS, he can return his own server's IP, and your browser will connect to the attacker's server showing the original name in the url bar. Fortunately TLS should save you because the attacker should not have a valid certificate (but it would save you also with OTP). If you disregard the TLS/HTTPS warning, then Webauthn breaks.