> wouldn't anyone serious about these particular options just choose to apply them in Nginx?
It sounds like you are assuming that everyone "serious" already is or should be using Nginx. Also one shouldn't assume that you'll always be using a reverse-proxy. Even when you are using a reverse-proxy, in my opinion it's good to keep that layer as "dumb" as possible, minimizing application-specific details. For example, setting certain security HTTP headers correctly often requires a deeper understanding of an application than one should expect from the reverse-proxy layer.
Slightly off topic, but it reminds me of why I think web application firewalls are misused: they try to plug security holes that should be treated as application bugs.
It sounds like you are assuming that everyone "serious" already is or should be using Nginx. Also one shouldn't assume that you'll always be using a reverse-proxy. Even when you are using a reverse-proxy, in my opinion it's good to keep that layer as "dumb" as possible, minimizing application-specific details. For example, setting certain security HTTP headers correctly often requires a deeper understanding of an application than one should expect from the reverse-proxy layer.
Slightly off topic, but it reminds me of why I think web application firewalls are misused: they try to plug security holes that should be treated as application bugs.