I'm trying to get a deeper understanding of SQL Server's inner workings.

First off there is a difference between surrogate keys and artificial keys. A surrogate key or blind key or meaningless is system generated and never ever shown to the user (we developers are not the 'users"). Joe Celko has no problems with those. Nor does C.J. Date.

An artificial key - (possibly invoice #) may be system generated but it's not a good relational key. Celko would not approve.

A natural key is composed of data elements.

Natural keys take more space in the storage pages.

Suppose there is a table with a compound primary key and said key is clustered.
When I insert a record, I'm taking an educated guess that because of the clustered index, the actual table is re-ordered in some manner if a new record falls between other records.

Same table - now the compound key is not clustered.
Inserting the record just updates the index and not the table.

Same table with a clustered surrogate key
if it is clustered, yet sequential, the table is unlikely to be re-ordered in any way but it could!

Same table with a non clustered surrogate key
only the index will be updated

Now - another scenario - I have a clustered meaningless key and a candidate key composed of the same columns as the compound primary key above.
The sequential key is updated, the record is added. No reordering of the table. The candidate key is updated.

So - considering all of the above, why would one chose natural keys for a clustered primary key? That seems to me to be worse than any of the other scenarios above.

Thanks for any guidance or clarification.