My personal experience and understanding of other languages is that idioms such as currying, partial application, pipe operators, and the endless array of other irregular application operators are far, far more useful in "pure functional languages" where it's actually possible to implement them in a fully generic way on any function and any arguments.
In Rust, I'm fairly sure this can never be as generic or as useful as it is in those pure functional languages because Rust doesn't have a GC, has both value and reference types, has both mutable and immutable types, and has the whole lifetime and ownership system which affects what function signatures are legal to call where, among other things. For instance, in languages that have a GC, partial application is straightforward to implement for any function because you simply don't GC the applied arguments until after the function finally gets called. These are also a lot of the reasons why functions and closures are (and need to be) two completely different things in Rust (as well as C++), unlike pure functional Lisp/F#/etc and even "impure functional" languages like Javascript (is there a term for this?).
Or more simply: I don't think there's any way around the fact that a function call in Rust implies way more machinery, and often cannot be pulled apart into tiny independently executable pieces.
This still makes sense as a crate, and is likely useful when working with Rust code that is designed to be used with more functional idioms, but I just don't see this ever applying to the whole language enough to make sense in std.