Names of a namespace, yes, but standards were meant to be broken. It doesn't really matter what you based the hash on, it's up to the application(s), much like the type of UUID you choose.
The reason I like UUID better is (once you pick a version) it's simple. It already looks pretty readable and it's a well known widely-used standard. It would have been nice if the authors of this RFC had just expanded on UUID. People are also way too URI-obsessed; when are you going to pass this hashed URI to an application? IMHO an object reference should be just that and not involve application interfaces.
In terms of the hashing algorithms, (IIRC) unless you're using HMAC you're opening yourself to an (eventual) brute force and key reuse issue, or at the very least the potential for an implementer to ignore the need for a random salt and get either easy collisions or predictable table insertion. I would feel pretty nervous if the hashing algorithm was my SPF.
But unless you rigorously enforce the hash=name convention, you can't get its benefits. (Benefits like stability and implicit verification.) And shoehorning the hash into the constrained UUID format hides/confuses the conventions you're committing to.
If you name is a hash, and really needs to be a hash, that should be evident, not squeezed into the bitfields of a 'UUID'.
