That's the so-called Garber-Irish technique that I briefly mention in the article. I want to investigate it further. I'm not sure whether to use classes or ids in the body tag or try the data-* attributes he suggests.
Also I'm a bit reluctant to use page-specific CSS selectors. It seems to be accepted practice (Modernizr and other libraries) but still seems like a hack. After all, there is never more than one body tag so it seems inconsistent with the HTML spec to apply a class or id to it.
The data attributes work great. They can fool you when you're not looking out for specific sitatuons. Like a typical error page will be show create or update action and not edit or new.
What? IDs and classes are part of the HTML, not the CSS, and as such, they should specify semantics, not presentation. If a class or ID specifies presentation, like .red-button, you have to change the HTML when the design changes, not just the CSS.
Sorry, just generally ranting, not in your direction. :)
My personal (strong) preference is to use semantic IDs as JS hooks (or just for markup readability), and keep all class names content-agnostic. Obviously there will be cases where you need to use (CSS) classes in your JS as well, so a good practice is to prefix them with js- and not base any style definitions on them. Separation of concerns and all that. You should be able to refactor your CSS, markup, and JS independently and not have anything break.
Additionally, you should be able to copy paste a chunk of markup and have it look identical no matter where you put it, which definitely won't be the case if you are using long, content-referencing selector chains. Keeping your CSS flat, low level, and generic increases reusability and prevents CSS bloat, which can quickly get out of hand even in a medium sized app. Of course, all this is probably overkill if you are making small, static sites.