The Windows API CoCreateGuid as an implementation detail produces GUIDs with a full 122 bits of entropy. The historical reason for this is that app developers got used to using CoCreateGuid as a cheap way to produce random data, and they would sometimes use that random data for security purposes (such as for keys or other sensitive identifiers). Eventually the OS and app security teams grew tired of the work involved in auditing these callers, so they said, "fine, we're just going to wrap CryptGenRandom and call it a day, because 122 bits from a secure RNG is better than the current state of affairs." And since .NET's Guid.NewGuid() API wraps CoCreateGuid, .NET developers have historically also relied on the same behavior.

On non-Windows platforms, we do not guarantee that Guid.NewGuid() is backed by a secure RNG. This could introduce subtle security vulnerabilities for applications which were written for Windows and which made assumptions about how our APIs worked on Windows but which were eventually deployed on a non-Windows platform. See the thread at dotnet/corefx#37906 (comment) for some further conversation on this point.

I've also created dotnet/dotnet-api-docs#4910 for us to document Guid.NewGuid() as "not guaranteed to be seeded by a secure RNG" - but honestly I don't think documentation is good enough for this. This seems like a pit of failure due to the different security guarantees made across the different platforms. This could be resolved by bringing the "yes, it's really 122 bits of fresh, bespoke entropy!" guarantee cross-platform.