The canonical example of a Warp rejection handler is
async fn handle_rejection(err: Rejection) -> Result<impl Reply, Infallible> {
But what's the advantage of a Result<ok, err> such that the err is Infallible and can never be reached? Why not just return an impl Reply?
It usually means one of two things:
The function is part of a trait, and the trait declaration indicates that the method can fail and return a Result<T, E>. Now, some implementations of that trait might happen not to have a fail path, and use an Infallible-like type for E.
A standard library example of this is the FromStr trait. FromStr can obviously fail when implemented on u32, but not when implemented on String. Therefore impl FromStr for String uses std::convert::Infallible for its error case.
The function is going to be used in a context that expects a fallible function.
This is the case in your example. handle_rejection is passed to warp::Filter::recover, which expects a fallible function. This makes sense as not all errors are recoverable, therefore recover might still have to deal with these.
Now, this is a toy example that happens to be able to handle all errors, and therefore use Infallible.