No, however it is not necessary. Some of your presumptions are incorrect to start out with. The things you point out as security issues are not necessarily actual issues. Let me go into more detail.
MDC uses SHA-1 and MAC-then-Encrypt
The MDC is designed to avoid a decryption oracle attack, as well as accidental corruption. Both of these issues are effectively mitigated even when using a "modest" hash function. In fact, even MD5 would likely not cause issues, considering the MDC acts similarly to a MAC where collision resistance does not matter. Using a stronger hash function would not give you any real benefit. In order to have actual integrity guarantees, you must digitally sign the message. That will prevent a large class of attacks that MDC is unable to. Overall, MDC is not designed to give a strong guarantee of integrity. It is neither intended nor capable of doing so. It is only meant to protect from a particular, obscure attack, and to give some protection against accidental corruption that may lead to decrypting a garbled message.
BLAKE2 and Whirlpool are not supported
For signing a message, a hash function is used. For this purpose, SHA-256 and SHA-512 are fine. In this situation, SHA-1 may not be ideal, and for this reason, it is being phased out in favor of stronger functions. While entirely different functions may be nice, it is not necessary for security. SHA-2 is fine. They are completely preimage resistant and have very good collision resistance. Also note that Whirlpool, while not endorsed by NIST, is directly based on AES, which someone who has no trust in NIST whatsoever may want to avoid (not that there's any reason to suspect it is particularly weak). The attacks that SHA-2 are vulnerable to (such as length extension attacks) are completely irrelevant to the way they are used in the OpenPGP format. When the need arises, more hashes may be added.
NIST curves are used for ECC
This is not entirely true. A NIST curve (P-256, specifically) is used when ECDSA is in use, but ECDSA is being deprecated due to the same weaknesses that regular DSA has. It is supported, but it is not recommended or required. Newer GnuPG versions have a non-NIST curve, specifically Ed25519 to replace ECDSA. It is not as well supported, but it is faster and has superior security. I'd also like to note that P-256 and other NIST curves are not "known to be compromised", as you put it. The issue with P-256 is that it does not use nothing-up-my-sleeve numbers, making it theoretically possible that the values were chosen to enable a class of yet-unknown attacks. There is no actual evidence for that, but it is good to be cautious. That's one of the reasons ECDSA is being replaced by Ed25519.
The real issues
There are actual issues with GnuPG, but they are not among the things you mentioned. These issues tend to be newer things which were not a concern back when the OpenPGP format was thought up:
Forward secrecy is not present. Compromising the private key allows retroactive decryption.
Post-quantum cryptography is not in use. NTRU would be great, but it just isn't supported.
The Web of Trust is hard to get right, so most people who use PGP tend to rely on TOFU.
GnuPG is very complex. For parsing complex formats, a tight seccomp filter would be nice.
PGP involves non-intuitive concepts, making it hard to use. This hinders adoption rates badly.