Of course, there are a lot of useful things a pure functional programming language gets you, like Haskell's implicit IO scheduling and threading, that Rust doesn't. But for many use cases where functional programming languages are great, they're great for specific reasons that Rust is also great at.
Also having actual purity knowledge (something Rust punted on before 1.0) can sometimes be useful. Although honestly 99% of the time it's only for the benefit of the compiler, which isn't a big deal if you have the tools to write code that's efficient from the get-go.
e.g. list fusion is enabled by purity, but is largely uninteresting in Rust because lazy iterator chaining already orders operations and avoids intermediate lists just like list fusion.
It's solving the same problems, and the solution ends up having many similarities with functional programming.
In my experience Rust is really close to OCaml in term of expressiveness. I don't know what feature Scala or F# have that Rust doesn't.
The only major thing I can think about is Higher Kinded Type in Haskell. They are indeed cool and there is work underway to add HKT to Rust (but nobody is sure yet if it's possible though).
I'm much more familiar with Haskell, which definitely has a lot of things that rust does not, not just higher kinded types but sophisticated type level programming, type families, functional dependencies, existential types, etc etc etc. Additionally it has lazy evaluation, a very sophisticated green threading system, software transactional memory, etc. Not to mention of course the purity. Haskell has a bunch that rust does not -- of course the reverse is true as well, but it's worth mentioning.
At the end of the day, though, rust is meant to address use cases that no mainstream functional language does, and it is very successful at it, while also having a ton of really cool features which makes it very exciting for FP enthusiasts.
See also: https://en.wikipedia.org/wiki/Type_class
Of course, Haskell type classes and Rust traits aren't the same. But they are quite similar!
fn do_something_with<S: Read>(source: S) {
// do something with input source
}Then you can do the following:
let stdout = io::stdout();
do_something_with(stdout.lock());
let file = File::open(path).unwrap();
do_something_with(file);
You're free to narrow down/expand the types/methods that can be used with the function if you add more traits.
I've sometimes imagined someone writing a paper about specialization and naming it "How to make parametric polymorphism less parametric" after Wadler's paper.