rust-crypto probably has a lot of google juice because it used to be the premier project. Then its team disbanded. While you're right that 2016 isn't super long ago, it was originally created before Rust 1.0.
Const generics will also help these sorts of interfaces significantly.
rust-crypto has the most upstream dependencies, but is an unmaintained, abandoned project.
There are a number of other awesome cryptography projects in Rust (in fact some of the most advanced cryptography in the world is being developed in Rust), but they suffer from an awareness problem.
The Go standard library's cryptography, while full-featured and very mature, does suffer from a particular problem: it's a mixture of high-level and low-level APIs all within a single namespace / module. This makes it difficult to compare to Rust projects, because it's an enormous omnibus library, whereas in Rust there is no equivalent to that because the projects are more compartmentalized, and in my opinion that arrangement is preferable to what the Go standard library is doing. See also:
The closest thing to an all-in-one crypto library is ring. There's a notable difference between ring and the Go standard library though: ring presents a very high-level, hard-to-misuse API. This makes ring unsuitable for usages where you want "shoot yourself in the foot" cryptographic primitives which are difficult to use correctly and fail catastrophically unless used as such.
For the Rust equivalent of these "shoot yourself in the foot" cryptographic interfaces like Go "crypto/cipher" types such as Block, BlockMode, and Stream, take a look at the Rust Cryptography project:
Miscreant is built on top of these, and presents an AEAD interface, which could eventually be upstreamed into RustCrypto so Miscreant just implements it.
But that's the thing: it's the premier project, and doesn't expose the simple interface that the Go library did.
Looking throw my code for cryptopals, I had to do these extra steps that aren't relevant to my problem (encrypting the plaintext with a key and cipher):
1) Create a mutable Vec<u8> vector from the plaintext.
2) Use that vector to create a mutable buffer of a type in the crypto library.
3) Create a second mutable Vec<u8> vector for the output.
4) Do step 2) for it also.
5) Call the encryption function with those two buffers as arguments. (This step's fine because calling an encryption function is unavoidable.)
6) Convert one of them back to Vec<u8> via `take_read_buffer().take_remaining().to_vec()`
(I'm ignoring the steps where you declare the key and cipher parameters since those are necessary)
And getting those to work required looking up the types of their library buffers.
But I don't care about the buffers where the library writes to when encrypting. I just want to be able to pass in a Vec<u8> and get a new one back out. At most, I should have to convert to and from the library's internal representation. Instead, I have to learn about and manage mutable variables and their ownership.
Const generics will also help these sorts of interfaces significantly.