The threat model you described did not take HPKP into account at all, and the existence of HPKP has a large effect on the question of whether DANE is worth the hassle (and the problems it comes with).
HPKP doesn't really solve these problems. It requires initialization, so a naive browser isn't protected at all. It also makes a bunch of smaller operators nervous because, if they lose their keys, it's game over. DANE gives a happy middle ground where you can easily re-key and only a small number of third parties can potentially tamper with the keying.
No, that is only half the HPKP story. The other half is that when a pin breaks in a browser, the browser can report it. Your browser might not have a certificate pinned yet (though: for the most important sites on the Internet, it does, because they're preloaded). But hundreds of thousands of other browsers do.
Every HPKP-enabled browser functions as part of a global surveillance system monitoring certificate issuance.
This works because under the TLS CA hierarchy, we have trust agility. When a CA screws up badly, they can be limited by the browsers (Chrome has repeatedly shown themselves willing to do that), or removed entirely.
DNSSEC+DANE gives us no trust agility. You cannot revoke .COM without breaking the Internet.
