The creation of a trueRandom function certainly seems to solve this problem more than taking away a useful tool for cases where pseudo-random is good enough.
It's really not clear cut in either way on the surface.
On one side, you can argue that leaning people towards true random will cause unnecessary performance impact because the majority of cases don't need true random.
On another side, the impact of not using true random could cause a catastrophic result for a large number of people.
So which has more weight? I dunno.
In either case, it would be nice if developers knew the consequences of using either method, so this discussion is really more about education than anything else.
>the impact of not using true random could cause a catastrophic result for a large number of people.
And the impact of using 1000x slower trueRandom could cause catastrophic results for an even larger number of people, since by far PRNGs are used where speed is more important than security.
And once you pick a "true random", how true is it? Will it be secure in 10 years? Will we then need a "truerTrueRandom" to mitigate that true random has failed to pass future mathematical or hardware tests? Will it return random numbers fast enough for future uses?
It's a rabbit hole. Let developers use the one they need, and since the vast majority does not need secure random, don't force it on them at significant cost.
If your crypto developer cannot know which to use you're going to have a lot more holes in your crypto than the RNG.
IMO there is no use of true random unless you really know what you are doing.
Also there is true random - pure entropy bits and there is cryptographically secure pseudorandom, seeded with true random bits.