Typically customer codes are sequential. Since they're not here, that would definitely make the clustering key choice much more difficult.

If customer code is (almost) always used for lookups/processing, you still save a huge amount of overhead by not having to go thru a nonclus index, which at minimum roughly doubles the reads to get to a specific row.

As I noted before, if the customer code is actually a customer number, it can also be stored as an int rather than as character. If it's alphanum, naturally that would also have to be taken into consideration.

I don't object to surrogate keys in general, just the idea that by default tables should be clustered by identity -- that's just laziness. There is no one-size-fits-all rules when it comes to determing the best clustering key for a given table.