I'm of two minds about this personally. On the one hand, I appreciate the argument that the only thing that can prevent businesses from doing something bad, stupid or abusive is if it's legally, physically or by design impossible. On the other hand, as a pro user, I do appreciate the ability to override software when it mistakenly tries to prevent me from doing something.
There are enough examples in the past that clearly demonstrate that developers are not benevolent or competent enough to have complete and final control over the software their users run. Sometimes this control even results in the exact opposite of what the developers originally intended, as was the case with firefox addons just a couple of days ago.
Ultimate control over software should always reside in the hands of the user.
This is really the core problem in security; the world is designed for people like this by people like this, without any serious thought for the implications for the overwhelming majority of users. Do not include "I know what I'm doing" escape hatches, and security will magically get better for the many at the expense of convenience for the few.
Let's give every user a tablet that has two buttons. You press one, you get a new cat picture. Press the other to "like it". That's all the user needs. All data exchange is end-to-end encrypted from the cat picture provider to tablet's input&video drivers - can't risk the spooks^Wcompetition knowing what they're looking at. They don't need to do banking - like everywhere else, they just sign a three-party contract with the tablet provider and the bank. This way, the Bad Guys can't steal users' money! Oh, the users also want to watch pictures of squirrels? There's a separate tablet for that pulling from separate provider; it's insecure to let these mix on one device!
Seriously, this is how the world would look like if security got its wish. There is a point past which security is essentially enslavement, and that's true both in physical security and computer security.
The credentials in these protocols depend explicitly on the verified FQDN of the server (and thus you can only use this with HTTPS). When scammer.example asks for your credentials there literally isn't a way to give it credentials for realbank.example. No matter how sure you are that you're a very smart person and definitely need to give scammer.example access to empty your bank accounts, no way to do this is available. Maybe next week you'll still be angry you couldn't do this, maybe you'll realise it was a scam, don't care.
This is why Google reports zero successful phishing for their own systems. U2F is mandatory there. Their employees aren't magical, some will fall for scammer.example and they will be really frustrated that they can't use their Google login like it says, and some will scream at their help desk team about how stupid this is, how it's totally broken, and even after they demand that the help desk person be fired and they change their password six times and write a ten page rant on their blog they still can't give their employee credentials to the scammer and Google remains safe.