We use IDENTITY because if gives us a single column, unique, value for each row. Where we have generic code of some sort, or we are trying to sort a problem out using Compare Scripts and the like, its a lot easier to guarantee that there is a single column unique numeric value [in the row] than having to have scripts that can cope with multi-column keys etc.
A very high proportion of our code (CRUD and the like) is mechanically generated, so that maybe makes my use-case unconventional.
Other things like ETL, Import/Export and then Merge into remote DB, where mechanically generated scripts are used the one-part key makes the "does it already exist" code easier and uniform, and so on. Nothing to do with our choice for clustered index, you'll be pleased to hear! - although do please take credit for the fact that you have raised it here often and that has made me far more vigilant on Clustered Index column choices than I probably would have been otherwise
Web Pages are referenced by having the ID in the URL. That's fine with "anything" of course, including multi-part keys, but that bloats the URLs and data in URL which contains spaces / non alpha-numeric characters etc. needs special handling and, for example, hyphens in URL causes their use in (plain text) emails to soft-line-break, and so on.
So basically my reasoning is that when I want to reference a specific record the option of using a small, single-part, unique identity value is often better than a conventional key, particularly if the only other unique reference(s) are multiple-part
Agree with all you say, but its the humans that are the problem!
They create X1234 in the database today. They create documents with names like X1234$20170714.DOC, they email them to other people, they put them in the document management system, ...
... and then they change the Reference on the record to Y1234 ...
There is no hope!