I'm not sure how browsers using the API would be a concern. Someone paid for the key, so it should be up to them to use it how they please (within rate limits).
Allowing browsers to query directly would break the terms of engagement specified by the site operator, who specified that a proxy shall be used to concentrate end-user requests for a given paid key. That’s their right as service operator. I can construct plausible scenarios why this is a sensible choice, but the underlying point is that they clearly regardless made that choice after thinking it through.
That’s not a requirement specified anywhere. The “Protecting the API Key“ section talks about using a proxy specifically in the context of client-side applications (think of things like 1Password that integrate w/ HIBP), where embedding the API key into the app is obviously undesirable. In those cases, using a proxy allows managing the request volume and injecting the API key.
That same section of the document describes other scenarios, like a hosted service or a CLI tool, that do not involve a proxy service.
I look forward to clarification someday from the operator - but that custom header will still block non-extension browser-side calls in v3, and I bet the ACAO header isn’t present to allow it either.