But, it's important to make the decision because a "crypto" psudorandom number generator may be significantly slower than an insecure generator.
This is critical for performance-sensitive operations. For example, certain audio and video codecs need to simulate noise. In these cases, high performance is much more important than cryptographic security.
In the overwhelming majority of cases, cryptographic random bit generation performs perfectly adequately. Insecure random number generation is wildly overused in our industry. CSPRNGs should be the default application RNGs on most platforms, and should always be the default choice for developers.
Which makes stuff like PCG even weirder! Because in most cases, what you want is a somewhat slower generator that has better failsafe behavior.
Many microbenchmarks intended to measure other things become benchmarks of your RNG if you use anything slower than an LCG. This biases a lot of places towards using the poorest RNG they can get away with.
This is made worse by many purchasing decisions made based upon microbenchmarks with the requirements of "default settings" so defaulting to insecure is a sound business decision in more cases than you might think.
This is indeed a tragedy, because it could have been easily avoided by including LCG in microbenchmarks. LCG is less than ten lines, so even for very short microbenchmarks including RNG is very feasible. Alas, I guess such reasonable people don't write microbenchmarks in the first place.
I understand the "broken benchmarks" problem and I acknowledge that there are some cases that are so demanding and have such low security sensitivity that it makes sense to have an LCG in the standard library.
But I stand by my argument that the default platform RNG should be a CSPRNG, and that developers should reach for a CSPRNG by default.
Which makes all the attention we've been giving to stuff like xoroshiro128+ and PCG pretty confusing to me. It feels like people arguing very earnestly about non-problems, while ignoring a huge problem in our standard libraries.
PCG is cryptographically secure, though. Or at least, it is as cryptographically secure as any other PRNG in the sense that nobody actually knows how to predict it, many have tried, nobody has succeeded, but nobody has proved it impossible.
This is critical for performance-sensitive operations. For example, certain audio and video codecs need to simulate noise. In these cases, high performance is much more important than cryptographic security.