The output of a CS_P_RNG is by definition reproducible. And there’s really only a small number of applications where, say, ChaCha8 would be too slow.

According to https://rust-random.github.io/book/guide-rngs.html

Chacha8 has a throughput of 2GB/s and xoshiro256++ has a throughput of 8GB/s

For Monte-Carlo, the RNG is definitely the bottleneck. For load balancing of short tasks the RNG is the bottleneck.

On my thermally-limited laptop, aes-128-ctr runs at over 9 GB/s. If pure speed is the goal, then AES-NI is faster than the fastest PRNG. Seek to a deterministic point by advancing the counter. Choose random seed with a fresh key. What more could you want? ("portable speed!")

You can eek out another 10% or so if you dial it back to the recommendations of the "too much crypto" paper: 9x AES rounds (versus 10).

https://eprint.iacr.org/2019/1492

I don't think GP is questioning the need for a good but unsecure PRNG.

What is questionable is the "somewhat secure" argument. Either you don't want adversaries to predict your numbers and you should use a good CSPRNG, or you don't care and predictability is not a property that matters.

As for reproducibility, all PRNGs give a reproducible sequence if you know the internal state, including the secure ones. You have to mix in a source of entropy to make them non-deterministic. The predictability we are considering here is when the attacker doesn't have access to the internal state.