MDC is not MAC, and there is no key confirmation in PGP.
RFC6637 was published in 2012, before rev 3 or even 2 of SP800-56A; as stated in section 15.1 it references rev 1 from March 2007. That was before NIST started assigning DOIs, and I don't know if you can still find rev 1, but I have a copy I saved, and the C(1,1,ECC CDH) scheme in 6.2.2.2 of that document, at that time not yet labelled '1e,1s', does not itself include any key confirmation but refers to optional use of 8.4.7, which adds a tag sent back from the recipient (V) to the originator (U) substantively the same as now described in 6.2.2.3.1 of rev 3. This was not specified for PGP and could not be used there because PGP is designed and defined to allow and include the case where there is no return communication from the recipient to the originator, and even if there was such communication there is no action the originator could take to respond to any failure here, making it worthless.
The MDC referenced in section 8 of RFC6637, as directly and clearly stated there, is the one in RFC4880 section 5.13 which defines
... a Modification Detection Code (MDC) packet ...
and explains:
The MDC system, as packets 18 and 19 are called, were created to
provide an integrity mechanism that is less strong than a
signature, yet stronger than bare CFB encryption.
...
The obvious way to protect or authenticate an encrypted block is
to digitally sign it. However, many people do not wish to
habitually sign data, for a large number of reasons beyond the
scope of this document. Suffice it to say that many people
consider properties such as deniability to be as valuable as
integrity.
OpenPGP addresses this desire to have more security than raw
encryption and yet preserve deniability with the MDC system. An
MDC is intentionally not a MAC. Its name was not selected by
accident. It is analogous to a checksum.
So the functionality of MDC is technically superfluous when you sign, but since the spec does not and cannot require signing, it is less complex to require the MDC even when it isn't 'really' needed (and thus somewhat harder to implement wrong).
