Quite apart from the DNSSEC example that Patrik sent, underscore labels also cause problems and confusion when aliases are involved. The alias stuff is a corner case, of course, but it's still a basic problem with the approach of specifying policy for a target name at a different name than the target itself. This trade-off might be a legitimate one (I certainly think it's preferable to the strategy SPF adopted, of stepping all over the TXT RRTYPE at a given name), but it won't do to dismiss the problem with a point-and-laugh argument.
Use of underscore names does impose some limitations. Occasionally those limitations are noteworthy for real-world operations, but experience across a range of applications so far has not created any show-stoppers.
One of the more serious problems about using the underscore construct is that arguments against it sometimes are based on an insistence for pure-and-complete original DNS capabilities, rather than attending to the real-world utility. It would be nice to have the construct impose no additional constraints, but 'nice' isn't the same as 'necessary', when evaluating pragmatic trade-offs.
In other words, the specific technical limitations being noted are unfortunate but (so far) not serious.
d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net