As mentioned in a similarly worded question (Why use bind over lambdas in c++14?) The answer was - no reason (and also mentioned why it would be better to use lambdas).
M
The paper that proposed it Simplified partial function application has some good compelling use cases. I will summarize them here, because otherwise I would have to quote most of the paper, so definitely go check it out:
Using a lambda would involve std::forward
boilerplate
In case of storing object by value std::bind
and std::bind_front
propagate constness, but in the case of capturing lambda the user must chose a mutable or const version creating problems
Using a lambda would involve -> decltype(auto)
boilerplate on the user side.
Like preserving mutability, except now we are talking about lvalue/rvalue and only std::bind_front
does this correctly
A consequence of propagating mutability and preserving value category
This is especially more important now since exception specification is now part of type system
cppreference has some useful notes as well:
This function is intended to replace std::bind. Unlike std::bind, it does not support arbitrary argument rearrangement and has no special treatment for nested bind-expressions or std::reference_wrappers. On the other hand, it pays attention to the value category of the call wrapper object and propagates exception specification of the underlying call operator.