But How Far is Too Far?
The argument for semantic naming has definitely become quite granular, and disagreements about just how far to go with semantics regularly break out between markup purists and designers, as well as other groups of folks developing sites.
A designer might name a column division #leftnav. At first glance this is logical, and in the context of smaller sites, maintained by one or just a few folks, there really aren't a lot of problems with this kind of naming.
However, consider a site the size of AOL or Yahoo, on which large teams of designers and developers manage millions of pages every day. And let's say that a design decision from high on up the corporate ladder is made to move the navigation to the right from its former home on the left side of the screen. Part of the power of CSS is that in a best-case scenario, all that switching the navigation would require is to go into the CSS and swap the column by repositioning it or floating it right instead of left. Save that file and then millions of documents are updated to reflect the change.
But now, millions of documents also have a division with an ID of #leftnav describing a column that appears on the right! Without doing a massive search and replace to change the ID name in the (X)HTML, the document is now very confusing to anyone who views source, or (more importantly) comes in to work on the site.
This is why avoiding presentation and choosing a more relevant description as simple as #nav or #subnav will be more useful in that kind of environment. So, even if it might seem a bit nitpicky, for very large sites we want to try and maintain the power of CSS and the purity of our documents. Smart class and ID names are a major part of that goal.