Why can inserting random UUIDs as Primary Keys be slower than inserting sequential Integers?

1. A UUID generation requires significantly more CPU clock cycles and complex mathematical entropy than simple auto-incremented integers.
2. B UUIDs are stored as variable-length string literals, which are natively incompatible with the database's internal B-Tree comparison logic.
3. C Random UUIDs cause 'Page Splits' and 'Cache Thrashing' as new rows are inserted into arbitrary locations in the B-Tree rather than at the end.
4. D Standard relational databases do not natively support the indexing of 128-bit identifiers, forcing the use of inefficient and slow custom hash-functions.