I favor using identities in *almost* every table, even those that have one or more natural unique keys. For one thing it makes logging much simpler, a single quad of log tables (one for each CRUD type) with a table ID, a RID (my term for a 4 byte identity), a date/time and some other fluff, and you're good to go. A single quad of triggers to write too. Gotta love the simplicity...

They also have the advantage of compactness, serialism, and thus speed. As clustered primary keys they're pretty hard to beat.

At the same time you should always index your unique natural keys, you're going to sort by them if nothing else. RIDs can't be the end-all of indexing by themselves.

The only time I don't put a RID in a table is if the table is a many-to-many table consisting of a pair of RIDs. Although even here if logging is critical for auditing purposes this table too will get its own RID PK.

I don't think it's a matter of using *too many* identities, it's a matter of not using them *properly*. Unless your table is over 2 billion rows (or likely to exceed that limit over time) identities are the clear winners from any number of perspectives.