A single column int or bigint will always perform better than some multi-column natural key with one or two char/varchar columns.
Performance is not the overriding concern. I use identity keys if there is no good natural key or at some point at three or four different columns I'll use an identity key instead. But then you have to ensure that the columns don't have what in reality is a duplicate, which I've seen in this type of design. A unique constraint would solve this, but what impact does that have rather than just making it the key to begin with.
Performance is a major concern when you're dealing with tens of millions or billions of rows in parent / child relationships with multiple levels, and wide tables at that.
Programming / development is made much easier by this as well.
I'm not current on the state of programming. But back in my programming days, when an identity was necessary and also involved a child table, it was not easy to add the parent, retrieve the generate key, and then insert the key. The SEQUENCE, which didn't exist in SQL Server when I was programming, helps that greatly. But I certainly don't see how it makes it easier. It may be harder. But that's not the same as easier.
I was speaking mainly about joining tables, and especially multiple levels. Having 1 column to join down to on each level is a huge plus, in terms of performance and clarity, and not to mention the data space savings in not having to have the upper level natural key columns repeated in your lower level table just to have the matching relationship. Surrogate keys rock. I'd rather have that one column relationship and do the key generation and insert downstream (an easy operation, really) when needed, which is rare. Stored procedures take care of that very easily when adding data normally.
To each his own... this entire subject is very polarizing for db folks.