There may be further reasons they don't want to ship crypto libraries as part of the Rust language distribution when it's not yet even properly out the door. That doesn't stop third parties from writing crypto libraries in Rust and then distributing them separately from the core platform.

I can think of a couple obvious reasons why they would take this approach: (1) Crypto is hard, and they want to get the core platform out the door in a usable form on a relatively tight schedule. (2) Designating an official Rust crypto solution would be a social statement about what crypto code you're supposed to use in Rust, even if the quality of the code itself is inferior due to being newly written and unvetted. This is riskier than just using existing C libraries, because at least now they can't be blamed for any horrible security bugs in libraries they didn't write.

If you'd only read past the specific sentence you quoted, you'd see that they do have plans to build crypto solutions in Rust, but that they're taking an extremely conservative approach to making it happen, and developing it "out of tree," ie. not as part of the Rust language codebase. Moving conservatively with respect to crypto development is not inappropriate. I'm sure you understand the sensitive nature of crypto libraries and why they need to be treated with as much care as possible.