Talking about GUIDs or UUIDs in this context is confusing.
The Key is either
- a function of the input (a hash, be it a "deterministic GUID" or otherwise) or;
- independent of the input, such as random GUID or auto-increment ID
All hashes for which the range (all possible outputs) is less than the domain (all possible inputs) will have collisions due to the Pigeonhole Principle. However, the idea is to use an appropriate hash for which it is improbable for a collision to occur, which is discussed in the linked questions.
Cryptographic hash functions also have additional goals, such as "it is infeasible to find two different messages with the same hash." (That is, even if someone was trying, it should still be impractical to generate a collision - MD5 fails here and is considered broken; and SHA-1 has been superseded by SHA-2.)
If the Key is independent of the data (e.g. is not a hash) then we might as well use an auto-increment ID - which is deterministic, albeit independent of the data, and guaranteed unique by the database - and call it a day.
So, using a Hash, the key is a form of a Natural Key that identifies data. This makes it possible to query the database with just the hash. And, if we trust that the client generated the hash from data on-hand then it can generally be assumed that the client has the data which results in the hash.
While using an "independent deterministic value", the Key is a Surrogate Key that identifies the tuple. In this case we need to query against the data to find the appropriate data if the "ID" is unknown. This of course requires that the client uses the original data in such queries.
Both of these approaches are valid in the appropriate context, and I use both in database design. (I generally prefer Candidate Keys to impose the multiplicity, but the result is the same.)