It's interesting to imagine how you'd maliciously use a TLS certificate for a major DoH provider (which does NOT appear to have happened here). Impersonating a DoH server would let you return any DNS responses you wish. DNSSEC would only protect against this sort of attack if the stub resolver performed the DNSSEC validation, which I think is quite rare. For HTTPS, the attacker would also need a certificate for the target domain (or trick the user into trusting an invalid certificate / downgrade to HTTP). This is not a compelling attack since it only compromises one layer of protection.
This is problematic for SMTP/email, as you really need a trustworthy MX response and, unless you have MTA-STS, TLS validation is usually not performed. DNSSEC/DANE could help, but it depends on where DNSSEC validation occurs.
It would, however, be a privacy concern as the attacker impersonating the DoH server would learn the queries and source IP addresses.
From a privacy perspective, the impact is further limited by the tiny number of popular zones that are actually signed --- you're two predicates removed from a useful attack (widespread deployment of clientside DNSSEC validation, which is very rare today, and widespread zone signing).
It's a weird misissuance from that perspective! Suggestive to me of something nonmalicious (nonmalicious misissuance is still a dealbreaker).
This is problematic for SMTP/email, as you really need a trustworthy MX response and, unless you have MTA-STS, TLS validation is usually not performed. DNSSEC/DANE could help, but it depends on where DNSSEC validation occurs.
It would, however, be a privacy concern as the attacker impersonating the DoH server would learn the queries and source IP addresses.