I think you are grossly overestimating the amount of tables I build :D. I mostly deal in backups,access, and troubleshooting. The only tables I've built have to deal with keeping track of server data for reporting such as server names, environments they exist on, if they are encrypted and so forth. Because this data inherintly doesn't have any unique values that isn't nvarchar, I would create an identity column such as serverid as a primary key and populate the table so that when I join, I'm joining on that serverid rather than something like servername to pull the data from the normalized tables that contain different server information.
And again "Something like a person entity, where there is really no set of attributes that uniquely identify a person?" if the IDENTITY inherently isn't unique, why would you ever use it WITHOUT forcing it to be unique via primary key,unique keyword, or unique index?