There are also other forms of GUID besides "random 16 bytes", as mentioned in the RFC. Some Microsoft products (SQL Server for instance) can optionally generate these "sequential GUIDs" which are based on a combination of "MAC address of first network card in the system + ever-increasing counter based on system time".
These "sequential GUIDs" have the nice property of always appending new records to the "end" of a database table when used as a database primary key with a clustered index. This helps prevent database index fragmentation and page splits.
If random GUIDs are used as database primary keys with clustered indexes, new records will be inserted randomly in the "middle" of a table from a physical allocation standpoint, which leads to index fragmentation and partially-full database pages over time.
Using sequential GUIDs still allows you to generate GUIDs independently on multiple systems and be confident there will not be any collisions (a property that you do not get using sequential integers as primary keys without allocating "ranges" or different seeds and increments to each system, which is an administrative nightmare in large distributed applications).