Public key pinning is scary. The technology’s purpose is to allow website owners to include a cryptographic fingerprint in outgoing HTTP headers that corresponds with the fingerprint of the server’s certificate; if the fingerprint in the headers doesn’t match the actual fingerprint, it could be evidence that something nefarious is going on. You might be the victim of a MITM attack, or the site might have been compromised, or you might be accessing a fake version of the site that has a legitimate (but falsely-issued) SSL/TLS certificate.
The scary part is that as with HSTS, a mistake with your HPKP configuration can make your site unreachable—potentially for a long time.
So why the hell do it?
Security researcher Scott Helme has some in-depth thoughts on HPKP, as does SSL Labs’ Ivan Ristic. The short version is that HPKP provides a significant amount of protection against a number of different potential attacks. The problem is that it does so with a pretty heavy hand; browsers presented with mis-matched HPKP fingerptints will block the display of a site for as long as the HPKP header has instructed them to, and that period of time might be weeks, months, or years. A misconfigured HPKP header will ruin potentially a lot more than just your day.
In spite of the scariness, HPKP is a useful thing to implement—it’s just got to be done right. Personally, I decided to push forward with my own HPKP setup for the same reason that I usually jump head-first into stuff like this: just like jumping head-first into a cold swimming pool, it’s best to get it over with.