I'll bite. Reasons that you might not only not want to use DNSSEC yourself, but also believe it's important for the protocol not to find any success:
* It creates a global tree-based PKI rooted in world governments (and, on the 2018 Internet, particularly the "Five Eyes" governments), many of which have already demonstrated an eagerness to manipulate Internet infrastructure to capture intelligence.
* Simply in order to reach parity with the (poor) security UX we have today, it will require major forklift-grade updates to libraries and code already deployed, because virtually all Internet software is written with the assumption that DNS lookups fail only because of network failures or user errors, and DNSSEC introduces a third basic class of failures. All this new code will be costly and that money could be spent on better things, and all that new code will be buggy.
* We now know from years of niche experience that our predictions about DNSSEC and reliability were right, that DNSSEC is rarely deployed reliably (major providers routinely screw it up), and that it creates frequent outages that wouldn't occur were DNSSEC not deployed in the first place.
Against these and other concerns you have to weigh the benefits of DNSSEC. But unfortunately for the protocol, the last 25 years of protocol development has proceeded based on the premise that the DNS isn't trustworthy to begin with --- you have to draw a line in the protocol "stack" somewhere, with "insecure" stuff below and "secure" stuff above, and we've essentially spent the last quarter century with that line drawn above DNS. As a result: the benefits of DNSSEC are marginal, bordering on vanishing.
It used to be that there was a coherent argument for DNSSEC around email; DNSSEC would enable MTAs to establish secure connections reliably. But major email providers have given up on DNSSEC even for that application: SMTP STS doesn't depend on DNSSEC.
