You are very right. This is indeed an excellent post thread with very educating inputs from all senior members.
This just about probability calculation part, if I may add a few points. As per my understanding, the probability of UNIQUEID() is based on the calculation as follows-
It is a UNIQUEID() of 8 alphanumeric digits long. Each digit can have 26 alphabets and 10 (0-9) numeric combinations, that is total of 36 combinations for a single digit. So for 8 digits , it will be 36 to the power of 8 which as per my understanding is 2.8 Trillion ( Calculator gives results as 2.8211099 E+12) @Steve may give more insights into this. I might have missed one possible combination, giving result as 2.8 rather than 28, but I believe the calculation basis is as described.
With only numeric digits as in RANDBETWEEN(), the probability calculation is simpler. Since it is only numeric, 2 digits 0-100 will give just 100 possible combinations, for example. In case of RANDBETWEEN(100000,999999) , the probability will be (999999-100000)=899999 or just 0.89 Million , very much lower from that with UNIQUEID()
However RANDBETWEEN(10000000,99999999) will give much better (99999999-10000000)=89999999 or 89 million.
Thank you very much @Suvrutt_Gurjar
That means, one would need to use RANDBETWEEN(1000000000000,9999999999999) to get 8.99 Trillion possible combinations? That would be a little bit more than with UNIQUEID().
Technically , yes a larger digit base with RANDBETWEEN() will increase the possible combinations. However, there could be certain internal limit with how many maximum digits can be included in RANDBETWEEN() function.