Closing 80 protects against a Mallory that has readonly access to the network between Alice and Bob.

Also afaik most http request libraries in many languages would not have such a guard?

eg: this code sample in go produces the raw header when I listen with nc https://go.dev/play/p/s1CaOVcGcxS

  nc -l 8080
  GET / HTTP/1.1
  Host: localhost:8080
  User-Agent: Go-http-client/1.1
  Authorization: Bearer 123123
  Accept-Encoding: gzip

Yes, because you configured it to go to http, not https. Usually if you have credentials to send you also have a domain configured for those credentials, and then you'd configure the correct address, right?

That's my whole point though. If you build an API but then its up to customers to integrate with you, you can help them avoid one of many pitfalls by not allowing them to do a dumb thing like send private headers over unencrypted channel

>because you configured it to go to http, not https. Usually if you have credentials to send you also have a domain configured for those credentials, and then you'd configure the correct address, right?

The "you"s in your sentence are actually 2 different actors the one doing configuring is often a not technically excellent client, the "you" who has a domain is the API creator, who can also help out the client by closing 80 or refusing non-TLS traffic on 80.