I'm sure there are valid reasons. Unfortunately, many sites disable it without a good reason, and in those cases, I am glad Chrome hinders their misguided efforts. Many banks, for instance, think password managers are bad and disable it. Chrome preventing them doing so is a good thing.
You can strengthen that... it is up to the users, as a matter of practical fact. I've right-clicked -> edit attribute -> autocomplete=true more than once. I've cleared the right-click handlers and keypress handlers that were blocking paste, or run $0.setAttribute("value", "paste your password here on the console where they can't stop you") (after you select the element in the inspector).
Browsers as they stand now are not capable of truly blocking autocomplete, or pasting into a field with an input box. If they aren't implementing their own text field with a canvas and taking keystrokes themselves they aren't blocking paste anyhow. (And if they do that I can still tampermonkey or something my way into a "paste".)
It's not up to Chrome devs to accept or deny viable use cases. As someone from comments mentions, it's in the spec, and chrome devs should not deviate from that irrelevant if what they think is accepted or not accepted use case. Or they should go and push for spec change.
I think predictability is important. And specs define what you can expect. System with undefined/unpredictable behaviour does complicate a life in long run even if at the moment it looks more convenient.
If the topic is predictability, I would expect banks to use the spec to disable only predictably non-autofillable fields with the user's best experience in mind. Disabling autocomplete on username and password fields in the name of some nebulous 'security' goal is neither predictable, nor in line with most user's expectation of usability; it also doesn't make the system more secure. I could argue that these sites themselves aren't following the spec by disabling the fields.
Remember, there are autocomplete values to accommodate "current-password"[1]. If your bank has a field representing a password without that attribute, do you think that's following the spec?
But it’s not useable at all. A form without autocomplete is perfectly useable. A form with autocomplete where it’s not wanted is an absolute hindrance.
That attitude basically endorses the idea that the spec is God-given. There's nothing so important about getting the spec changed before you start ignoring it.
> That attitude basically endorses the idea that the spec is God-given
That's a tad over-dramatic. And context matters, surely I don't need to remind you why Google is spending so much money on Chrome?
Having a company control 70% of the browser market is bad enough, we don't need people telling them to go ahead and ignore specs, remember that they don't make those decisions out of goodwill for us.
Any business SaaS app where users like customer service representatives input data about their customers. Name, address, email, payment information and so on. Under no circumstances should these sort of input fields be autofilled.
Every time I logon to a certain system, Bitwarden types my password then I get a TOTP prompt. And it offers a pulldown menu half a screen long of previously entered codes.
But as soon as browsers stop autocompleting fields marked with autocomplete="one-time-code", won't website developers start marking _all_ input fields with this tag? After all, why do people put autocomplete="off" on input fields anyway?
autocomplete="one-time-code" causes a different type of autocomplete behaviour, it doesn't disable it. Specifically for example it will suggest a one time code you received by sms if one was recently sent (on mobile at least).
Search fields. I don't want it filling in the users address or email address when they're searching for a customer.
We have customer service representatives that accept orders over the phone, including credit card numbers. These should not get stored by the browser as autocomplete data.
