I don’t have a concrete answer to your question about benefits, but I do fear that my example didn’t illustrate what I actually had in mind. So if I may try again.
What business do you have trying to sort a “thing” that doesn’t have isless defined on it? Shouldn’t it just have an isless method? If it has the wrong islessmethod defined on it, then you can introduce a new thing that has the desired behavior. That’s what the wrapper was meant to illustrate.
The arguments to the sort function feel to me out of place, actually (I know there is a history in other languages of sorting functions taking in these kinds of arguments). Why doesn’t the maximum function take in an lt argument too? Or for that matter, any function that calls isless, why doesn’t that function take an lt argument? That’s what the first API would do.
Once you define isless on your type (your thing), then you can use min, minimum, sort, you can use the lexicographic ordering induced by isless on NTuple{Thing}, and so forth. (So, here’s a benefit of the second API)
I understand that sort has this interface almost as a convenience. Sometimes you want to introduce a very context-specific notion of isless that you don’t want anywhere else in your program. And it could be a pain to define a new type with the appropriate behavior. (This is a benefit of the first API)
On the other hand, defining new types with new methods is favored in other contexts, e.g. defining new Number types with different arithmetic behavior.