If queries which scan a range of primary key are used very often, you may want to cluster on the primary key; where the primary key is multi-column, that includes the case where queries that pick a single value of some of the columns are common (and which such queries are common may tell you what order the columns should have within the primary key). If queries that come from outside the database normally use the primary key, you should not use a surrogate as primary key but that doesn't necessarily mean you don't want to cluster on the surrogate instead of on the primary key - or indeed want to cluster on something else altogether. It is somethimes reasonable to write joins using the surrogate but still specify the natural key as the primary key and cluster on something that is neither the primary key nor the surrogate. You may find that where a table is not a gateway to the database the besy choice for primary key something which is a surrogate derived for use in joins in a parent table which uses the natural primary key - and you may find this even when the parent table clusters on the natural key if for example the child table has far fewer rows than the parent.

It all depends on what the query workload and the row counts look like.

I think Grant's advice in his comment above is spot on.