A good reason not to do DNSSEC validation is that it adds significant unreliability to your network (DNSSEC deployment failures happen all the time, with what appears to be higher frequency than TLS certificate failures, and DNSSEC failures are more dramatic and disabling than TLS failures) while adding only marginally to security, and then only in the best case --- there are cases where it reduces security.

The security of my SSH servers is not influenced at all by the integrity of my DNS queries. If I had a fleet of servers and a large organization of people to secure, such that I was concerned about the security of user introductions to SSH servers, I would address that concern directly with certificates, not indirectly with DNSSEC.

What's more, there are other good things that fall out of adopting SSH CAs (simplified provisioning being the most noticeable, short-lived credentials being the most important). Whereas there is basically no upside at all to adopting DNSSEC, and a lot of downside.

DNSSEC is bad, which is why nobody uses it.

Note that I was referring to client/stub resolvers specifically. Last time I checked, it was rather uncommon for them to perform their own DNSSEC validation rather than trusting the AD bit sent by their upstream resolver. In practice that means any MitM between you and your DNS resolver can spoof DNS regardless of DNSSEC status. DoH/DoT, on the other hand, mitigates this.