No, it's subtly harder than that. It's not that some clients will get a better experience than others, it's that in an environment of widespread reliability issues, browsers and other TLS clients will need to develop a downgrade protocol to handle the cases where DNSSEC lookups don't work. That downgrade protocol will inevitably break, like every other cryptographic downgrade ever tried.
By way of example: until a year or two ago, the last great hope of DANE was on stapled DANE records as a TLS handshake extension. No DNS lookups would even be required. But then, years into the project, somebody realized that attackers would just be able to strip those extensions off of handshakes. The only thing that prevented the attack was the Web PKI roots of trust --- which is what DANE was trying to augment in the first place.
What would prevent what you're calling "stripping" is that a client which wants to see DANE records won't accept the "stripped" connection because it doesn't have any DANE records and none are stapled. That's true for any imaginable mechanism, if you "strip" the intermediates with conventional Web PKI certificates you're in the same place, if the client has the information already (e.g. a modern Firefox) the connection works and security is maintained, if not the connection fails.
The stapling RFC was deliberately sabotaged, by the browser vendors and they more or less openly admitted that. Not their finest moment. The TLS WG (dominated by people working for the browsers) adopted the stapling work saying we'll run with this, and then after stalling for several years they basically said this doesn't do what browsers want (it's for DANE and the browsers have decided they don't want to do DANE) so we aren't going to publish.
This is a great way to be an asshole, and if that was actually the goal (which it appears was the case to at least some extent) then I guess bravo.
My understanding of what happened and what you're talking about is that the antidote to this problem was yet another continuity mechanism, like pinning and HSTS; it doesn't protect first connections, and is a contraption.
To a first approximation, DANE is essentially a browser protocol. Obviously, things besides browsers speak TLS, but browsers are the overwhelming primary audience. If the browsers don't want to do DANE, that's a very strong signal.
Sorry, I have more to say about this.
I feel like there's a general attitude among some IETF people and DANE bystanders (especially people from the European DNS community) that feel like browsers are arbitrary, capricious gatekeepers of how TLS works; that we could have working DANE everywhere but for lazy browser people who don't want to work through the deployment drama, maybe?
But that overlooks the fact that the Web PKI is a partnership between the browsers (the root programs in particular) and the PKI providers. Neither side is working entirely on its own, both sides are sort of intensely engaged with each other. We have the Web PKI we have now, with free automated issuance, transparency, and toothy CA revocation, because of a real (if fraught) partnership.
Nothing like that appears to exist in the DNS community? Tell me I'm wrong. Why should I believe any of this would work?
By way of example: until a year or two ago, the last great hope of DANE was on stapled DANE records as a TLS handshake extension. No DNS lookups would even be required. But then, years into the project, somebody realized that attackers would just be able to strip those extensions off of handshakes. The only thing that prevented the attack was the Web PKI roots of trust --- which is what DANE was trying to augment in the first place.