The article mentions DNSSEC, but is that a limiting factor in this case? If you are connecting to a server you specifically have out of band access to then just use pre-shared keys like normal and none of this is relevant. If you don't and DNS is compromised then you're depending on DNS anyway right? At that point getting the host pubkey from DNS too doesn't seem like it hurts anything and it could still defend against MITM if the chain from you to DNS is different then you to the server (not uncommon I'd think, since a lot of people are either using their local resolver, using their ISP's at 1 hop, or using someone distributed like Cloudflare who are also minimal hops). Of course authentic secure DNS is really important anyway, and worth working on. Beyond DNSSEC there is also DNS over HTTPS. And just using shared keys and nothing else, no option to even accept if it changes, is best of all. But if that doesn't work for whatever reason having it in DNS doesn't seem like an awful idea, anymore then Let's Encrypt depending on DNS does right?
Authentic secure DNS is in fact not important, and is not worth working on. I think the lengths you had to go to just now to establish some kind of marginal value for SSHFP is a good illustration of why. And that's because we've designed protocols for the past 20 years to assume the DNS is insecure. SSH, in particular, has "don't trust DNS" baked into its DNA; it's a response to the old Unix r-commands, which did trust DNS.
The threat model SSHFP protects against from is some adversary that's in the middle of you and the server (not close to you or the server). It does nothing against an evil ISP or evil AP, which FTPS (with CA signed certificates) does protect you against.
