Reason to use anything other than RecId as a clustered index

Question

Is there any reason to use an index other than RecId (SurrogateKey in AX2012) as the clustered index?

Confirmed by a quick Google search (*), one should consider at least 4 criteria when deciding on clustered indexes:

1. Index must be unique.
2. Index must be narrow (As few fields as possible - since these would be copied to every other index).
3. Index must be static (As updating the index field value(s) will cause SQL server to physically move the record to a new location)
4. Index must be ordered (Ascending / Descending).

RecId adheres to all of the above, in a better way than any index you can create yourself. Any index you create yourself will violate at least the 2nd and/or the 4th, since it would automatically include DataAreaId.

What I think...

Could it be that the option to set this is just a legacy property from AX3.0 or lower, and that its use could be deprecated now?

*TechNet SQL Server Index Design Guide and Effective Clustered Indexes

Answer 1

While RecId is a good choice, you can make a shorter key on say an int on a global table (SaveDataPerCompany = No).

Access patterns matters, if you often access your customers by account number, you might as well store the records in that order.

Also, if you only have one index as is often the case for group and parameter tables, you are not punished for having a longer key, it will need storage somewhere anyway.

See also What do Clustered and Non clustered index actually mean?