UUIDs/GUIDs are desirable when you want multiple, independent, computers creating Globally Unique IDs.
But the suck as a PRIMARY KEY.
They are big -- 36 characters, worse if you default to utf8, which is overkill. The hex in them can be converted to BINARY(16). In InnoDB, the PK is appended to every secondary key, thereby multiplying the space cost of a bulky PK.
They are random -- Once you have more data than you can cache, you are usually hitting the disk for every fetch. This drops your performance to ~100 operations/sec. Just when you need scalability, it is taken away from you!
If all writes are done to a single Master, then use AUTO_INCREMENT: MEDIUMINT UNSIGNED up to 16M, INT UNSIGNED up to 4G, or BIGINT for the insanely optimistic.
As for the CPU performance of VARCHAR, BINARY, INT, etc -- that's not the issue. The issue is the bulkiness of the key because that leads to the cacheability of the INDEX, which leads to I/O being the bottleneck. If everything can be cached, don't worry about the key type and size. (OK, the datatypes in a JOIN must be the same, or close enough. Different collation, for example, destroys the usability of an index.)