I agree with this. IMO, everything that needs a (secure) PRNG should take a reference to the PRNG as a reference so that the caller can choose which implementation to use.
The presence of rand::random() is at odds with this. Realistically, however, people are going to want something like rand::random(); crates that use ring's ring::rand API often manually implement the equivalent of rand::random() on top of it, for example. Thus, I think it might make sense to retain rand::random() in light of this. However, that doesn't mean it needs to be especially fast.
OTOH, std::HashMap doesn't follow the aforementioned rule of taking a &rand::Generator (previously, &rand::RNG) during construction, so it has to use rand::random() unless/until new constructors are added for it. IMO it is acceptable to regress performance for the current constructors when adding the new constructors, but perhaps not everybody agrees. I expect there would be a lot of objections to forcing fast HashMap construction to require a &rand::Generator, since that would mean that all code that can construct HashMaps would need to thread the &rand::Generator through, which I think people will think is awfully inconvenient, especially since they probably don't care about this issue as much as I (we?) do.
Could std::HashMap have an internal private rand::Generator? Kinda like what's behind io::stdin, initialized on first use, provide a hook to poke in the Generator you want.
(In addition to explicit constructors for people who care about properly-randomized HashMaps.)
For std it seems easy enough to have a reasonably-fast, cryptographically-secure, nearly stateless default RNG: just use the OS RNG directly without any additional algorithms on top. In terms of state, this requires opening a handle at most once per process.
Update: We've got an actual RFC pull request now folks. Hopefully discussion can move there so that it's all in one place instead of spread across here + 2 places on github.
Personally I do not see CryptoRng as a promise of secure random numbers, but as a way of handling potentially-fallible generators
Bikeshed: It might be better to call it FallibleRng or something like that rather than CryptoRng, since the RNG isn't necessarily cryptographically secure, and having "Crypto" in the name of the trait is misleading.