I've read in a couple of online articles pertaining to the performance of using UUID's as primary keys in MySQL - and a common theme, whether they are for-or-against is the idea that non-sequential data hurts index performance.
https://blog.codinghorror.com/primary-keys-ids-versus-guids/
The generated GUIDs should be partially sequential for best performance
https://www.percona.com/blog/2014/12/19/store-uuid-optimized-way/
Create function to rearrange UUID fields and use it (after showing how rearranging UUID can drastically improve performance)
However, I simply cannot understand how non-sequential data impacts indexes such as B-TREES, HASHES, CLUSTERED indexes.
You can add my UUID blog to your list. (It applies to MySQL equally well.)
Note that the performance problem does not occur until the index (whether clustered, or not whether BTree, hash, or other) is too big to be cached in RAM. At that point the "next" UUID you reach for (or try to insert) is unlikely to be in RAM, thereby necessitating I/O, which impacts performance.
In contrast, inserting rows keyed on a datetime, and doing so somewhat chronologically, will mostly be inserting into the same block of a BTree. This means that the "next" row is unlikely to need I/O.
I/O is the biggest factor in performance.
My blog points out how Type 1 uuids can be turned into something akin to a timestamp, thereby achieving the "locality of reference" that leads to less I/O, hence more speed. MySQL 8.0 has builtin functions that do the same thing as my Stored Functions. Still, you need Type 1 and need to call the function, in order to decrease the I/O.