Any rule that has the word "always" in it is usually a bad rule.

Surrogate keys are generally preferable, but there are countless cases where they are not. Consider an audit table that contains only a single column: the timestamp an event occurred. That value will *never* change. Period. Adding a surrogate will vastly bloat the table (by 100% if you're using a smalldatetime), double the number of required indexes, force page lookups whenever you need to perform a join (since your PK is no longer a covering index). And in return, gives you -- nothing whatsoever.

The only reason to ever surrogate-key a table like that is if multiple rows might possibly have the same timestamp. But in cases where business logic forbids this, there is no reason to do so.

Now you may rightfully ask "what if your business logic changes in the future". If there's even a remote possibility of that, then you likely want to bite on a surrogate key anyway. But in cases where that just isn't possible because of the data being modelled, then a "always use surrogate rule" is pointless and damaging.