It really depends on how your application/site manages the certificates and public keys, i.e. how often are the keys and certificates rotated. For example, if your site rotates the certificates very often, then you'll also need to update your application that often as well, if you are pinning the certificate. Whereas, in this use case, pinning public key will be a better idea since the public key associated with the certificate will remain static.
From the OWASP link that you mentioned in the question:
Certificate
The certificate is easiest to pin. You can fetch the certificate out
of band for the website, have the IT folks email your company
certificate to you, use openssl s_client to retrieve the certificate
etc. When the certificate expires, you would update your application.
Assuming your application has no bugs or security defects, the
application would be updated every year or two. At runtime, you
retrieve the website or server's certificate in the callback. Within
the callback, you compare the retrieved certificate with the
certificate embedded within the program. If the comparison fails, then
fail the method or function.
There is a downside to pinning a certificate. If the site rotates its
certificate on a regular basis, then your application would need to be
updated regularly. For example, Google rotates its certificates, so
you will need to update your application about once a month (if it
depended on Google services). Even though Google rotates its
certificates, the underlying public keys (within the certificate)
remain static.
Public Key
Public key pinning is more flexible but a little trickier due to the
extra steps necessary to extract the public key from a certificate. As
with a certificate, the program checks the extracted public key with
its embedded copy of the public key. There are two downsides two
public key pinning. First, its harder to work with keys (versus
certificates) since you usually must extract the key from the
certificate. Extraction is a minor inconvenience in Java and .Net,
buts its uncomfortable in Cocoa/CocoaTouch and OpenSSL. Second, the
key is static and may violate key rotation policies.
Regarding the MitM, no, your TLS connection will not be vulnerable to any MitM attack as long as you've implemented the certificate pinning correctly. Even if an attacker is able to get a valid certificate for their own domain with the same public key which your application has pinned (through a rouge CA let's say), they still wont have have the corresponding private key. Thus will not be able to create a valid TLS connection with your application (since they will not be able to perform TLS handshake itself).
