It depends. I wrote a blogpost about the security implications of UUIDs back in February (https://blog.silentsignal.eu/2017/02/17/not-so-unique-snowfl...) and it shows that not all standard libraries make secure-by-default easy for the developer. I developed a MIT licensed plugin for Burp Suite (https://github.com/silentsignal/burp-uuid) that can help pentesters and security minded developers to detect insecure UUID versions, and even in that plugin I described version 4 UUIDs as "randomly generated, although [their] entropy should be checked".
You need to double check the library you're using. For example, older versions of the Python standard UUID library would fall back to an insecure RNG silently.
It's easier to just read 16 bytes from /dev/urandom and encode it in hex/base64 yourself for a random token.
Getting pedantic, but a proper uuid lib should be returning 122 bits of randomness, and six bits of fixed information that specify the uuid version and generation method ("random").
For what purpose? Where's the real world reason and interop? Just because an RFC says to set some bits? Is there any code you're likely to hit in your app that actually cares?
I guess the purpose is to be able to put different UUID generation schemes into separate kind-of "namespaces".
That way, a UUIDv4 (random) will never collide with a UUIDv1 (timestamp+mac+...), which again will never collide with UUIDv5 (SHA-1).
So if one of the UUID generation schemes is flawed, these are easily filtered out, and moreover, will never interfere with any other UUID version/scheme.
