It doesn't talk about this subject. Only about generating lots of
independent SQL queries to test the robustness of the SQL processor.
It's fascinating - but not apropos.

Familiar with it.

As an aside, Postgres had random number generation functions in 1993.
In fact, that system developed an entire class of optimizer
modifications to cope with the general class of 'non deterministic'
functions, which includes 'rand()', but just as easily might apply to
'has_the_missile_been_fired_yet()'. It was pleasing to see SQL Server
arrive at the same conclusions 15 years later. <snark off>

  I'm intimately familiar with this literature. There's also an
excellent discussion in the more recent _Numerical_Recipes_ books.

  But how do you know what RNG these products use? Did you see their
source code?

  Writing a very good RNG is not hard. It's 10% scholarship, 10% code
effort, and 80% testing.

[ snip ]

  There are a large number of RNG algorithms which, when handed the
same seed, generate the same sequence of values, making it possible to
use of the same list of random values as often as one would like.

[ snip ]

And is the same set of numbers used repeatedly. Which means
subsequent samples derived using the same table of values -- or
samples derived from other sources using the same table of values --
are no longer independent.

[ snip ]

 A raft of other practical problems present themselves with the use
of a static table. I'll describe one of them.

 To use that table of random numbers, you need to plug it into a
query somehow. This means either a) modifying the table to add a
column containing a random value, or b) writing a join. Now the
problem with either approach is that a query processor--not being
aware of the random nature of what is going on--is going to move the
restriction or the join operation to wherever the physical planner
sees fit to place it.

 Confronted with these problems -- customers wanting bernoulli
samples, for instance, but getting instead samples whose size
distribution was all over the shop -- DBMS vendors added random number
generators and sampling algorithms to their products in very deep
ways. It's not just the quality of the RNG that counts. The whole
query processor needs to change.

 And even then, users wonder why the sampling query is no faster than
the original. So they added yet another layer of complexity to make it
go fast, as well as generate "statistically rigorous" samples. (Note:
They're not. But they're usually good enough for government work.)

 In a nutshell, DBMS vendors (well - the one or two I am most
familiar with) added random() functions and sampling with enormous
care. They deal with a small number of very, very sophisticated
customers who subject these products to tremendous amounts of
validation. If these customers are disappointed, they get upset. (If
they're happy they never say so. Such is life.)