Marie, in this case, I think the derived table just makes it more obvious what the query is doing than the "WHERE...IN" version. SQL should only have to actualize the recordset once either way though the join might be a little more effecient; I'd have to test a few cases to see if it mattered. Note that I generally avoid the IN and NOT IN constructs where possible since it usually results in the query optimizer generating a giant "OR" block to test each condition.
When you use a correlated subquery (essentially a sub query that uses fields from outside its parenthesis), SQL may execute the statement once per row that it needs to filter. In these cases, joining a derived table should almost always be more efficient, though this isn't the example in the article.
There's one other case that she didn't mention... What if you were doing a query for last order by Customer Name and your system doesn't have a unique key on name? I don't know of a way to do this without either setting up a temp table before running your aggregate query, or using a derived table. Maybe this only comes up when the schema is poorly defined, but I have found it relevant when querying third-party databases. (Specific case in point: we have such a database that allows SSN's to be duplicated in an employee table; when looking up aggregate data per employee, I have to get the most recent employee id number for each SSN and use it when agregating data for each employee.)