There's certainly a lot less cruft to Rust's standard library than other languages', but there's certainly cases where libraries end up doing a better job than std for certain applications. What parts of std might you replace with a 3rd party lib?
I've got a couple of the notable ones to start us off:
std::sync::mspc is pretty generally understood to be suboptimal at best. Both flume and crossbeam-channel are popular choices for replacements that outperform std's channels in most ways. IIRC, flume's been under consideration for uplifting into std.
std::collections::LinkedList is almost never actually what you want. Most of the time, you're just good and probably better with Vec instead. In the cases you actually benefit from a linked list, you probably need more invasive control than std's LinkedList can give you.
A fun one, std::env::home_dir can give bad results on common platforms, and as such the std library suggests using a 3rd party crate for the functionality instead. Where to store files is a surprisingly difficult question to ask, let alone answer, and has potentially unexpected issues cross-platform. The home crate is what's used by cargo/rustup. Do your own research here, though; I'm very uncertain what the tradeoffs are.
It used to be that std's Mutex, Once, etc. weren't all that great, due to specifics on how they were using the OS primitives to ensure safety, and parking_lot was just generally a better choice. However, std's synchronization implementations were improved significantly, and now it's much more of a trade-off between different implementation choices, with parking_lot having the benefit of greater cross-platform consistency, but std benefitting from using the OS's primitives.
Similarly, std's float parsing used to be suboptimal, and likely will be again in the future in the lag between new algorithm development and std adopting them. Before the most recent iteration of the cycle, lexical greatly outperformed std both in accuracy and speed, but currently std's implementation is in a very reasonable position for the tradeoff between code size and performance.
And of course, we've got to mention hashbrown, which beat std's HashMap implementation so concretely that std now quite literally uses hashbrown's implementation. The only reason to use HashBrown directly currently is if you want/need to use the raw entry or raw table access it provides.
More in the trade-off zone, you might consider using camino instead of std's Path{Buf}, if you can guarantee that your application won't ever need to deal with non-wellformed-Unicode paths.