8 Years Later:
I must conclude they know something bad about DNSSEC that overweights the benefits offered by it.
Not necessarily. Just as any other technology, the question is what incentives are there for involved stakeholders?. If you take a look at ICANN's DNSSEC report you can see that nearly all TLDs currently support DNSSEC.
So why consumers do not use it? Well it is also not easy to answer. In general if you don't want to go through the hassle of running your own name servers, you are dependent on the registrar to take care of some features such as DNSSEC. A Study by Chung et al. in 2017  showed that "only three of the top 20 registrars support DNSSEC when they are the DNS operator". Even if your name server is properly configured to use DNSSEC, there is no guarantee that users use (recursive) resolvers that are DNSSEC-aware and properly verify DNSSEC records .
Poor security usability for the end-users is probably another negative incentive for potential adopters. Compared with TLS, where you'd get warnings and errors directly in your browser in case of invalid certificates, there is no visual cue for DNSSEC (you can check if a website is signed or if your resolver validates DNSSEC on https://internet.nl/).
To give another twist to the whole story, lack of DNSSEC is sometimes desired by some parties. DNS poisoning for example opens the door for domain impersonation which can also grant you a domain validation (DV) certificate  which practically enables you to spoof a legitimate entity even with a valid certificate (green padlock in the address bar). Another example is the
tr TLD which does not support DNSSEC; now combine this with how the government of Turkey once abused DNS for censorship you can draw your own conclusions.
[...] and that you can walk DNSSEC records and find out all records in your domain.
This is not the case anymore with NSEC3.
I forgot to mention RFC 3833, which not only enumerates DNS security threats, but also weaknesses of DNSSEC:
- DNSSEC is complex to implement.
- DNSSEC significantly increases the size of DNS response packets.
- DNSSEC answer validation increases the resolver's work load.
- Like DNS itself, DNSSEC's trust model is almost totally hierarchical.
- Key rollover at the root is really hard.
- DNSSEC creates a requirement of loose time synchronization.
- The possible existence of wildcard RRs in a zone complicates the authenticated denial mechanism considerably.
 Chung, T., Levin, D., Van Rijswijk-Deij, R., Maggs, B. M., Wilson, C., Choffnes, D., & Mislove, A. (2017). Understanding the role of registrars in DNSSEC deployment. Proceedings of the ACM SIGCOMM Internet Measurement Conference, IMC, Part F1319(July), 369–383. https://doi.org/10.1145/3131365.3131373
 Chung, T., Van Rijswijk-Deij, R., Chandrasekaran, B., Choffnes, D., Levin, D., Maggs, B. M., Mislove, A., & Wilson, C. (2017). A longitudinal, end-to-end view of the DNSSEC ecosystem. Proceedings of the 26th USENIX Security Symposium, 1307–1322.
 Schwittmann, L., Wander, M., & Weis, T. (2019). Domain impersonation is feasible: A study of CA domain validation vulnerabilities. Proceedings - 4th IEEE European Symposium on Security and Privacy, EURO S and P 2019, 544–559. https://doi.org/10.1109/EuroSP.2019.00046