Clients directly accessing the server also makes sense when you have tens of thousands of open connections at a time (that would be me). The proxy overhead is just silly.
As for HTTPS, isSecure is interesting when using something like warp-tls so as to handle insecure connections more elegantly. While the server can't know about if a proxy received a secure connection it can know if it did. This is even interesting when using a proxy since if the proxy is on another system it should still connect with HTTPS for a large number of threat models. Of course one may put that in the Vault.
And don't forget CDN updates where connections that were being sent as HTTPS start being sent as HTTP due to the CDN operator's error. Perhaps you still want to serve most connections when they come in as HTTP from the CDN, send a warning to the ops team, and deny some requests as too sensitive? Plenty of cases here.
This isn't about the entire history of the connection, it is about conveying the webserver's information to the app so the app writer can make appropriate choices to figure out what the history actually is given their specific situation.
-davean
PS: The below happens BTW:
client <-> their work's proxy <-> their ISP's proxy <-> CDN <-> provider's proxy <-> final HTTP server
That is forwarded 4 times. Of course someone in there can also be lying. I've even seen some pretty clever goes at forging X-Forward-Fors through (or around) proxies.