>uuid field

This one is good.

I kind of wish it were default for primary keys, since the number of times I got burned by having databases I couldn't easily merge (which UUIDs help a lot with) way exceeds the number of times I had performance/memory issues caused by actually using UUIDs.

Databases aren't my field, but I would expect this to hurt performance by decreasing locality of keys.

This, of course, assumes that temporally-adjacent additions are related, but this seems like a common case for large data sets since they often arise from a series of measurements or transactions.

I created this account to make this reply because I imagine that someone here is expert enough to set me straight if I'm mistaken.

Postgres at least will store rows roughly in insert order. So whether you're using integers or UUIDs for primary keys won't affect on-disk layout.

When scanning the index, the database will be traversing it in btree order, anyway, so as long as the values are comparable, ints or UUIDs shouldn't matter much.

It might negatively affect performance, yes.

Performance shouldn't affect the decision to make it default, however. That would be premature optimization.

The only good reason I can think of for not making it default would be backwards compatibility.