Out of the remaining monads that are in common use (Result, Option, Future), it doesn't seem particularly worthwhile to try cram them all into the same API, when you could instead try to design better specialized APIs (as has been done with Future)
In practice applicative functors are even more prevalent than their subset, monads.
If you can express your algorithm using the weaker applicative combinators only, there's more opportunity for optimisation and parallelism. (And the code is easier to understand for your readers, because there are fewer interactions for them to worry about, too.)
I just implemented the Haxl paper in Java as a weekend project (for implementing GraphQL APIs), so it totally does ;)
I think you're being a bit short-sighted here.
I fully appreciate that it might be extremely difficult to accommodate these HKTs, etc. in a language with the core values of Rust. That's absolutely fine, because that's probably several research-level projects in and of itself. OTOH, we shouldn't discount the value of such things.
It's absolutely fine and reasonable to choose e.g. efficiency over other things, but it's not the only value.
(Of course you still want some form of nicer notation than the raw one, but that's beside the point.)