You are mixing up concepts that counter vastly different threat models and thus you question is hard to answer.
Let's say a hypothetical connection path would look like this:
A <-> B <-> C <-> D <-> E <-> F
with
A
being the client,
B
being a public WiFi you are connected to,
C
being the ISP of the WiFi provider,
D
and E
being intermediate hops between ISPs and
F
being your target to which A
is connecting.
VPN
A VPN establishes a secure tunnel between your machine and the end point of the tunnel, not more. In the example path, this would cover B and C, maybe D. This has several benefits if you do not trust your local ISP; maybe because that ISP is a public WiFi or otherwise untrustworthy and is expected to sniff your traffic:
- If you use HTTP, it can only be sniffed (and modified) from the VPN provider onwards,
- If you use HTTPS, your DNS queries cannot be sniffed (from
B
or C
), thus hiding (from those) which sites you're visiting.
Either way, you do not hide your DNS queries from your VPN provider or its ISP.
An additional benefit is pseudonymity; you do not leak your ISP-assigned IP-Address, but that one of the VPN provider, adding an extra layer of depseudonymization to identifying you.
HTTPS with Public Key Pinning
Public Key Pinning (mainly) defeats two threats that would inter-operate:
A man in the middle (B
, C
, D
or E
) that would break up the otherwise secure connection between A
and F
,
A rouge certificate authority that creates certificates for 1. to be able to present to you and be validated correctly.
A sub-threat to this would be that a dishonest CA could be installed in your trust store (e.g. by HTTPS proxies used in large organizations to actively inspect HTTPS connections for threats - but those are usually considered OK.
Public Key Pinning can thus defeat MITMs that can (for whatever reason) present (otherwise) valid certificates to break up the communication. This would allow B
,C
,D
or E
(not mutually exclusively) read and/or alter your HTTPS traffic.
Conclusion
A client that uses HPKP (correctly) is reasonably safe, albeit reducing usability: the before-mentioned HTTPS proxies would make communication impossible when it would otherwise be possible. In such cases, VPNs are usually not allowed, so a VPN wouldn't improve usability there.
A
does however gain pseudonymity towards F
by using a VPN, yet that is probably defied by an authentication feature within the application.