Davidson: There is no problem with using large Natural Composite Keys in general, but using them for your clustering key can be problematic. Every non-clustered key has the entire clustering key in it as additional key columns. So, if you have a 30-byte key for your clustered index, and then 10 non-filtered indexes, each row will at least take up 330 bytes, just for clustering keys. Most of the time, using a surrogate key for the primary key that is 4 or so bytes will be more efficient, and if sequential, even more efficient. Hence, the general performance suggestion of using sequential integers as a surrogate key is a common starting point. Just always keep in mind that this sequential integer value doesn't really have a meaning and should never get a meaning. It is simply there to stand in for the natural key for performance reasons.
Kline: A friend of mine once told me about how their team did a major refactoring of a database where they switched from natural, composite keys to surrogate keys for their clustered index. They kept the composite keys for covering queries and to reduce key lookups if I remember correctly. They ultimately saved about 200Gb on a 1TB database and reduced their IOPs by about 20%. It was a dramatic improvement and well worth their time.