Just to add: https://w3c.github.io/html-aam/#att-autocomplete-form says

If the element includes both autocomplete and aria-autocomplete attributes with valid values, User Agents MUST expose only the autocomplete attribute value.

there is overlap, but they aren't entirely equivalent.

also from HTML AAM:

Note: the ARIA attribute and the HTML attribute have disparate features.

there may need to be some more nuance to that user agents MUST in html aam... the intent there was likely to handle situations like <input autocomplete=name aria-autocomplete=inline | none> where the aria version is implying there's an inline autocomplete (type ahead) or no autocomplete, but the HTML attribute would render the browser's popup of saved names (a an autocomplete list).

but, to the point of the OP, <input role=combobox aria-autocomplete=list autocomplete=off ...> wouldn't be right - because there we do want a list to display, just not the browser's list (though lol, some browsers still going to show their autocomplete popup regardless - regardless of if a dev or user wants it to show or not)

The HTML Accessibility API Mappings 1.0 (W3C Editor's Draft) spec needs some editing clarification:

section on 3.6.12 autocomplete - form

• should clarify what is applicable only to the form element, and remove the remaining confusing comments not applicable to the form element.

section on 3.6.13 autocomplete - input, select and textarea

• should clarify what is applicable only to the HTML input, select and textarea elements.

Remove the confusing & redundant comment :"If the element includes both autocomplete and aria-autocomplete attributes with valid values, User Agents MUST expose only the autocomplete attribute value." or at least clarify which element(s) and why it should follow this convention when the ARIA attribute and the HTML attribute have disparate features. And explain what is valid (and invalid) overlap if any.