That one really bewildered me too. Suddenly there's no motive for having a unique element on a page, and styling it's children accordingly? Nonsense.
It all boils down to reusability though. If you have an ID, say for a #promoCol, sure, there may only be 1 promo column on the page now, but what happens when the client/designer says, hey we need a promoCol on the right side as well? Do you go back and refactor #promoCol to .promoCol (as it should have been originally, IMO), or just add #promoCol2?
Maybe a column is a bad example as you might be able to deduce ahead of time that there MIGHT be more than 1. But you could say that of just about any element on the page. Theater was mentioned, but I've worked on sites where we had to add a second theater second to a page (yah...I know, wasn't my call.)
I would even go so far as to say, if you use IDs in any significant factor in your CSS, you are doing it wrong. And it has absolutely nothing to do with knowing how to work specificity, and everything to do with the additional flexibility not using IDs provides you (or your co-workers) both during an initial build and down the line when maintaining or updating a project.
Yeah, that's exactly what you do. Just because your new dev doesn't know how to refactor (and it's hardly even refactoring, it's like a two-line diff) doesn't mean we all shouldn't use IDs.
IDs have an extra bit of self-documentation when you use them - when I see #promoCol, I know instantly that there's just one promocol, and I don't have to worry about breaking the look of another promocol while I'm fiddling with the CSS in there. If there's a class, you don't know how many things it applies to until you've done a grep over your project.
I love IDs because I don't need to think about changing a class to fix one page only to see the same class screw up another page.
For an example of where ids can trip people up, start at slide 66 of this presentation: http://www.slideshare.net/stubbornella/our-best-practices-ar...