If you're setting your headers with PHP you've already lost. Headers should be handled at the webserver level (e.g. Apache/Nginx), not in your server-side code.
IMHO, I don't think a broad statement about where headers should be handled can really be made. For the one liners, sure. You can set up HSTS once and forget about it.
For something like CSP, it becomes very difficult to maintain a list of sources very quickly. Also, for parts of CSP like nonces too – from a usability perspective, it's a lot easier to pass a nonce around in the application layer, as opposed to generating it at the Apache/Nginx level, and then trying to insert it into the HTML as the page goes out.
Goal here is to make things like CSP easier to use. Integrating security headers into a language devs are already familiar with achieves that.
Yes of course, for all of those times when your webserver should decide the Content-Type header instead of the application serving the content. /s
Seriously, though, for headers like CSP, where the value is dependent on application logic (in this case, which domains the served document will need to access), it entirely makes sense to set the header in your application. The same applies to caching headers. Your application is the one that knows what the ETag of the document is, not your webserver.
