SSH does have certificates, but in practice most people using SSH don't use SSH certificates and don't check the fingerprints.
Not sure if we can say it's solved if nobody wants to use it by choice (certificates are probably mostly used in enterprise setups, but in my experience it's not even that common there).
If you have a small, stable number of hosts, an SSH PKI doesn't make a lot of sense. With a large fleet, and/or if you want to tie your fleet into an OIDC IdP, certificates are pretty common; the most common way of solving this problem, I think?
I think it's the case in big companies. But most companies are not big :-), which means that a lot of people are using SSH without ever checking the fingerprint. That would be my intuition.
SSH has always relied on key continuity for this problem; you're exposed when you're first introduced to a host (on a particular client) but then fine from that point on.
This of course breaks down with cattle fleets where ~most logins are to hosts you've never hit before, which is why cattle fleets tend to use SSH PKI.
Over the years I have seen - repeatedly - colleagues just removing ~/.ssh/known_hosts when SSH showed the warning that says something like "YOU MAY HAVE BEEN HACKED!!!".
I think passkeys resolve that, even though it's more of a human issue than a technical issue :-).