The scenario mentioned by @17cupsofcoffee has happened to me several times, TBH (e.g. clippy telling me to use is_empty() over a len() check, and me accidentally flipping the condition).
It wouldn't surprise me for my code to have cases where insufficient test coverage has even let this cause bugs in my code 
. That's not to say this is anybody's fault other than my own, but an replacement for s.len() != 0 that's 1-to-1 identical in meaning seems like it would pull its own weight.
Regarding multiple ways to do something, as mentioned by @mcy, Rust already has many of these in e.g. the Option API (obviously map_or is the same as map + unwrap_or, and, for that matter, unwrap_or is redundant with unwrap_or_else -- same for most other other non-_else methods). Which is to say, I don't find that argument compelling.