I can't think of large differences. What comes to mind are two human factors that both speak against it:

- Having an HTTP error page informs the developer they did something wrong and they can immediately know what to fix, instead of blindly wondering what the problem is or if your API is down/unreliable

- That page, or a config comment, will also inform the sysadmin that gets hired after you retire comfortably that HTTP being disabled is intentional. Turning something off that is commonly on might be a time bomb waiting for someone who doesn't know this to turn it back on

Edit:

Just saw this reason, that's fair (by u/piperswe) https://news.ycombinator.com/item?id=40505545

> If the client can't open a TCP connection to port 80, there's no unencrypted path to send the API keys down

If that immediately errors out on the first try, though, what is the risk of the key being intercepted? The dev would never put that in production, so I'm not sure how the pros and cons stack up. I also loved this suggestion from u/zepton which resolves that concern: https://news.ycombinator.com/item?id=40505525 invalidate API keys submitted insecurely