This is not entirely true, as you may have multiple names that resolve to one address, with only a single PTR record. If you put the names of upcoming products and such in your domain names, you may find that NSEC3 offers some protection (at least if you change the salt often enough to prevent brute-force attacks). But if you don’t care about zone walking, there are many advantages to using NSEC, not just simpler signing and smaller responses. In particular, some recursive resolvers already use cached NSEC responses to synthesize NXDOMAIN responses (https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse-08 – currently only Unbound and Google Public DNS). This can provide some mitigation of random-prefix DoS attacks on your authoritative name servers.  The RFC does describe the possibility of using cached NSEC3 responses but this is more complicated, and because of NSEC hashing, the effectiveness is reduced (the recursive resolver has to cache many more NSEC3 responses to get the coverage it can get from much smaller sets of NSEC responses.

It is absolutely true that there is no point ever using NSEC3 for reverse (in-addr or ip6) .ARPA zones, since you can use NXDOMAIN responses on partial results do an efficient search of only the populated parts of the zone time proportional to number of domains in the reverse zone rather than the number of addresses in the delegated name space (in other words, even IPv6 is no protection). See https://tools.ietf.org/html/rfc7707#section-5.1.4.

A reasonable split-the-difference approach can be to use NSEC for your domain’s top-level zone (example.com) where the domain names are likely to be “www” “mail” “smtp” and so forth, and only use NSEC3 for delegated subdomains where confidentiality may be more important (dev.example.com).

@alex