regarding when the non-clustered pk might be good, the oversimplification is that if you do a lot of updates, you probably want the table clustered on the PK, because you probably select the records based on the pk. If you do a lot of selecting on ranges of values, e.g. reporting, you _might_ want to have a pk clustered to assist with that. To be clear, I _rarely_ override the clustering of a table, and it takes a lot of analysis to make sure you're doing it right, (and it's not hard to do it wrong) but it's not a tool I'd choose to give up.

As for surrogate keys, I was specifically thinking of a link table representing a many-many relationship.