There are several methods to generate UUID. The method 4 involves using 122 bits from a random generator. If that generator is cryptographically strong, then the UUID is a good secret key. But it can be hard to ascertain whether a specific implementation of UUID generation uses method 4 with a strong PRNG. In general, UUID are meant for uniqueness, not unpredictability. For a secret authentication token, you really need the latter. For example, if "type 1" UUID are used (combination of the system MAC address and current time), then attackers can easily infer what UUID your system will produce for other users.
That being said, in a given system, you could manually use a strong PRNG to get a 128-bit unpredictable sequence, which would be a sort-of UUID with the needed characteristics.
Providing the authentication token as part of an URL that users can bookmark has an other issue, which is that users will bookmark it. Storage of secret values on a desktop computer takes some care. Browsers apply that care for cookies, not for URL. In particular, URL may be displayed (and typically will). This would be a problem in exactly the same sense that you would not like a Web page that shows your password: people having a glimpse at your screen may gain too much information.
Also, bookmarks are synced up (when you use such a feature) while cookies are not. Accessed URL also make it your saved "history". This is part of the "extra care" bit I was talking about. Generally speaking, URL tend to travel and be copied a lot more than cookies, and are less protected against unwanted inspection. This makes them less appropriate for secret values, such as an authentication token.