You just said the same thing you said previously with more words and a bunch of RFC cites. If you store your PGP key in the DNS, then the entities that control the DNS can control your key. That they are "public keys" is immaterial; the point of a public key stored in a public ledger is that other people can rely on that key to safely send you a message, which they clearly cannot do with a key stored in the DNS.
Even if you believed DNSSEC is a good system --- nobody should; it's bad, and moribund --- a secure messaging system with end-user keys anchored in DNSSEC-protected records would be an incompetent design, on its face, simply due to the basic core architecture of the DNS and DNSSEC.
A different line of arguing may be helpful: not even GnuPG validates DNSSEC signatures (source: https://dev.gnupg.org/T4618 ). That's why DNS key discovery schemes are not enabled by default there (WKD is).
It’s not the job of GnuPG to validate DNSSEC signatures; that’s what a DNSSEC-aware resolver like BIND, Unbound or Knot does. If you’re not using such a resolver, all bets are off regarding trusting anything in the DNS.
But it’s certainly easy enough for GnuPG to check the DNS flags to verify the resolver has validated the DNSSEC signatures, therefore authenticating the openpgp record for its use, which is the point.
This is how DANE records work; SSH doesn’t validate DNSSEC signatures either but that doesn’t stop it from using SSHFP records in the DNS when they’ve been signed.
Even if you believed DNSSEC is a good system --- nobody should; it's bad, and moribund --- a secure messaging system with end-user keys anchored in DNSSEC-protected records would be an incompetent design, on its face, simply due to the basic core architecture of the DNS and DNSSEC.