that doesn't really make sense though. how would you know the range to sort by? presumably you'd use the criterion directly to sort.

a better reason and justification to not use UUIDs is that they take up needless space if you're space constrained. they also have worse performance

Maybe you are doing some sort of cursor for pagination or whatever. You can use one ID and fetch the next 50 records. Then use the last ID in those 50 to fetch the next 50, etc.

but you can still do pagination with uuids, your rows can be sorted on any arbitrary criteria like created date or updated date.

But that would be slow, even with an index, as compared to using a clustered primary key. Especially when your data doesn't fit in ram.

Sure, already mentioned UUID’s being slow. There are trade offs

Dates might not be unique but I can see other possibilities that would be fine.