No, SSHFP is pretty silly as a motivating use case for DNSSEC. There's nothing it does that you can't do (better!) with some other system. It makes sense if you already have a secure DNS. But that begs the question of why you would need a secure DNS.
You don't need a secure DNS for the web.
You don't, with STS deployed, need a secure DNS for email.
Is publishing SSH key fingerprints so important that we should do a forklift upgrade of the DNS? No, of course not.
STS information is stored in DNS records. Why would you not want to secure those?
Also, I think you're underestimating the growth of DNSSEC deployments. I've been watching DNSSEC growth for about 2 years and it is steadily moving up and to the right.
It has taken two decades to get to this point. The protocol has been substantially revised four times, and, after each of those four revisions, DNSSEC proponents said "now, we've got it right, and it's ready for universal deployment".
It is nowhere near ready for universal deployment today, and, indeed, virtually nobody relies on it, unlike TLS.
DNSSEC ain't pretty. I'll agree with you there, but that doesn't mean it isn't the best thing going for us in terms of securing the DNS. Like it or not it's important to be able to trust DNS responses.
I guess I don't have some expectation that deployment should take place quickly. Or that the first go at a protocol is going to always get it right. Just because a journey is difficult doesn't mean the journey isn't worth taking.
DNSSEC and TLS are unrelated. They're trying to solve different problems.
You don't need a secure DNS for the web.
You don't, with STS deployed, need a secure DNS for email.
Is publishing SSH key fingerprints so important that we should do a forklift upgrade of the DNS? No, of course not.