GUID vs Auto Increment Insert performance
What you are missing is the setting of innodb_buffer_pool_size (assuming you are using InnoDB), and how it compares to the size of the index on id.  The "more data" needed:

SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
SHOW TABLE STATUS LIKE 'guid';



When id is AUTO_INCREMENT or some kind of "increasing" timestamp, all the work will be done at the "last" block of the index.  Hence, very little needs to be cached to avoid I/O.
When id is a uuid/guid/md5/etc, the cache space used (buffer_pool) grows as the table grows.  This is because the id is jumping around "randomly".  You won't notice much performance hit until the buffer_pool is no longer big enough.  Then things gradually hit the fan.


Let's carry things even farther...  Let's say the buffer_pool that can hold 1M entires, but there are 20M entries.  When the next row is to be inserted, it has a 1M/20M chance that the desired block is currently cached in the buffer_pool.  That is, only 5%.  Or, a 95% chance of a "miss" -- almost always requiring a disk hit.  I/O is the major cause of sluggish SQL.

More discussion:  http://mysql.rjweb.org/doc.php/uuid

Bottom line:  If you have a huge table, guids will kill performance, whether it is the PRIMARY KEY or some other index.