From the perspective of the client, it does not matter where these headers are implemented; only whether they are implemented at all.
But, from the perspective of deployment, a WAF should be treated only as an additional line of defense and not as the single line of defense. This means that proper input checking should be done in the web application itself and proper setting of security headers too, at least for most of the headers: HPKP can of course only be set on the TLS endpoint owning the certificates which might be the WAF (if it should be set at all since it is deprecated).
Setting the security headers in the web application itself is also better from a development perspective. As much as developers should know what the expected type of specific inputs is and how they should be checked, the developers also know about how the application works and what for example the tightest Content-Security-Policy can be. A WAF is instead often deployed by a different team which does not have deep knowledge of the application and therefore cannot easily set the security headers to the tightest values acceptable by the application.
Therefore it should only be set in the WAF if it cannot be set in the application itself, which might be the case with third-party applications. As an additional line of defense, though, a WAF may still be used to ensure that the headers are there and sufficiently strict, since it might be that the developers forgot to set them.