So, I'm not a design purist. If I were, I'd argue that ONLY the natural keys should ever be used. However, there are very valid performance and design reasons why you might want to use a surrogate key, such as an identity (ID) column or a globally unique identifier (GUID) column. When you do this, as most people will, not only is it OK to mix the surrogate and the natural key, I'd argue that it's vital to ensure that the table meets functional requirements (ID or GUID to manage behavior & speed) and business requirements (the natural key that makes the row unique) both. Now, the real debate starts on which of these two unique constraints should be made into the clustered index. That's where things get fun. Personally, I've found the easiest way to answer that question is to use the most common path to the data. Depending on the situation, this could be either the surrogate or the natural key (although, it can be other column or columns that are not even unique, but I'd shy from those as much as possible). The behavior of the application and the queries drives this decision.
Hope that helps.