alt Hacker NewsRust has clearly opined that they prefer a small standard library and a "choose your own libraries" vs "batteries included" approach.
If Rust included a crypto lib and a vulnerability was discovered, many fixes are backwards incompatible. Rust maintains strict backwards compatibility, which means updating the relevant crypto functions in the std lib would necessitate a major version bump. By keeping crypto outside of std, it allows the community to make backwards incompatible changes at a higher pace.
Python handles backward incompatibility changes via multi-year deprecations. I'm not familiar with Golang but a quick Google search reveals that it deals with this by using feature flags via GODEBUG. Excessive feature flag use is a bad pattern in my experience years ago, but I don't know if that's applicable here.
I prefer the trade-offs of a "choose your own lib" approach, but I understand the advantages and preferences of those who prefer a "batteries included" approach.
In general, I get your argument, but cryptography is the perfect example for something so well-specified, well-understood, and extremely widely used, that these arguments do not really apply. You are not going to have to make backwards-incompatible changes to SHA256 or Poly1305, etc. It has minimal API surface too, and is not going to be a large maintenance burden. But nearly everybody is going to need crypto at some point. It is great to have blessed and well-audited standard implementations that people can rely on, without even having to make a choice. This it is not something where you want “the community to make backwards incompatible changes at a higher pace.”.
Crypto is something any modern language should include in the stdlib, imo.