That's 16 bytes instead of 8 bytes for a uint64 that still grants you 18,446,744,073,709,551,615 variations. Seems overkill, particularly if you actually generate GUIDs "correctly" in which case you've allocated 16 bytes but will only ever use a sub-set of them[0].
ObjectId is a 12-byte BSON type, constructed using:
a 4-byte value representing the seconds since the Unix epoch,
a 3-byte machine identifier,
a 2-byte process id, and
a 3-byte counter, starting with a random value.
You can actually convert the _id to/from a timestamp, which lets you do cool things like never keep a timestamp field (you can convert a datetime to an ObjectId and use that for comparison).
If the 4 bytes are unsigned, then did they just intentionally introduce a year 2038 problem?
12 bytes is enough to just store a random value, with low chance of collisions until you've got around 100 trillion items. It confuses me why anyone would want to waste bytes of an ID on low entropy values like machine and process ID.
Or any combination of high res time plus random works nicely.
OTOH, Mongo's not exactly been a bastion of engineering excellence.
