Meh. He advocates adding 'js-*' class names for javascript binding for example, which I find less elegant than using 'data-*' attributes. He also appears to be making a somewhat confused case against the movement for semantic class names over presentational ones, an argument that I found entirely unconvincing tbh.

On the 'js-*' class names, I agree that data attributes are a better way of selecting and organising elements which have additional JavaScript functionality, but it still makes sense to use supplementary class names to indicate state that may have been changed by JavaScript – otherwise your CSS starts to rely heavily on the inefficient [attr] selectors (also, not an option if you need to support IE6).

On presentational class names over semantic ones, I didn't get that from the post. He's talking mainly about the concept of Object-Oriented CSS, and that class names have no bearing on semantics – we have new HTML5 elements and RDFa+Microdata for that. Sensible class names provide maintainability for the developer over additional data for the end user or bot. Multiple classes on elements or additional elements (span, div – no semantic value) are preferable to attempting to make your CSS work with as little markup as possible, at least when working on a large scale site or app.

If you're interested in this approach, or just want a bit more context then I recommend reading some of the work of http://csswizardry.com/ and http://www.stubbornella.org/ who both speak a lot on this topic.