Why would you ever want to use UUID format, which only has 122 bits, versus just making a random 128 bit number? In which realistic scenario would simply reading 16 bytes from urandom not be fine and actually cause issues that removing 6 of those bits to identify the UUID type help?
Also, 32 bit timestamp + 128 random? I guess, but that sounds sort of overkill-ish - if you're going to go to 20 bytes (and thus not fit in a DB's UUID type, require more than 2 registers, etc.), why not make it 24 or 32 bytes and have a proper timestamp? Or if 32-bit timestamp is really acceptable, are you sure that 96-bits of randomness are not?
One of the things I've found strange about UUIDs is their serialization to hex when displayed as a string, yet I've seen real life projects with little technical debt store them as a string in a database. This is obviously the fault of the programmer, but you have to look at that and think if you're serializing to a string (whether that be in a database or over the network), there are so many better options.
AFAICT the only reason is that you need it for compatibility. If your variant and version fields aren't valid, you don't have a UUID anymore -- you have something else.
Compatibility with what though? What's an example of a real world system that takes UUIDs and uses the standard to do stuff with the fields? Does any popular software treat them as anything beyond a 128bit number? Genuinely curious what people are giving up 6 bits for.
Also, 32 bit timestamp + 128 random? I guess, but that sounds sort of overkill-ish - if you're going to go to 20 bytes (and thus not fit in a DB's UUID type, require more than 2 registers, etc.), why not make it 24 or 32 bytes and have a proper timestamp? Or if 32-bit timestamp is really acceptable, are you sure that 96-bits of randomness are not?