You're still going to have the "who can you trust" problem. If you're worried about a compromised disk controller then you ought to be worried about a compromised BIOS or TPM too.
This sort of attack is usually going to be more trouble than it's worth to execute, but that doesn't mean it's out of reach for a motivated, educated individual.
The point is that it's the same kind of attack. Relying on the BIOS may save you from an attack on the disk firmware but that doesn't much help if the same class of attack is still effective against the BIOS.
I'd bet most systems see different disk controllers more often than they see different BIOS chips. I'd bet (though not at so high odds) that reasonably secure TPM chips are relatively easier to find outside of the high-end server niche. I'd bet that most non-state actors executing this sort of attack wouldn't have equivalent exploits ready for many different types of hardware.
All of those factors shift risk around (again, what little risk there is from this sort of vulnerability). Forgetting about patching a hole here because of an equal-sized hole over there is silly.
"That isn't supposed to happen" doesn't mean it won't happen. The Titanic wasn't supposed to sink.
The point is, you want to be able to recover from attacks. It isn't about security today. The premise here is that you've already been compromised to the point that the attacker may have been able to screw with the firmware on your hardware. What you need then is not an assurance that the thing that already happened not be very easy, what you need is a way to hard reset the hardware to a known-good (i.e. factory) state given the assumption that every piece of EEPROM in the machine has been replaced with malicious code. Having something like a jumper on the logic board that will do that in hardware would be a welcome security feature.