To fully answer the question, we should look under the hood of Java to see what lambdas (at lest as of now) are: syntactic sugar for implementing interfaces with exactly one method. Let's explain it with the example of Comparator<T> (which is perfectly fine to be implemented by a lambda) and go over to Comparable<T> (which can be implemented by a lambda, but does not make sense).
Suppose someone has given us a (compiled)
public class Car {
private final int horsePowers;
private final int topSpeed;
private final int numDoors;
private final String color;
// Setters omitted for brevity
}
We cannot modify this class, but we want to sort cars by, e.g., color. The traditional way would be to call Collections.sort(List<T> list, Comparator<? super T> c). Since we, as developers, are often lazy (otherwise, we would not use Copy-Paste-Programming), we often implement this kind of stuff in an anonymous class:
...
List<Car> cars = ...;
Collections.sort(cars, new Comparator<Car> {
@Override
public int compare(final Car lhs, final Car rhs) {
return lhs.getColor.compareTo(rhs.getColor());
}
});
This is ugly. First, it is long and second, it is awkward to read. But luckily the Java gods have blessed us with lambda expressions, so that we shall write1:
...
List<Car> cars = ...;
Collections.sort(cars, (lhs, rhs) -> lhs.getColor().compareTo(rhs.getColor()));
This looks better, doesn't it? It's short, comprehensive, and pleasant to read (at least, if you have seen it a hundred times). But under the hood, it is still an old, anonymous class. Nothing else. Some limitations do apply though to lambdas. First, the lambda does not have any state (instance variables). Second, all references used from outside the lambda (local variables or attributes of the surrounding method/class) must be final or effectively final (the lambda is not allowed to change the value). This will get important further below.
Now, let's come to Comparable<T>. While a Comparator<T> defines how to compare two T's with each other, Comparable<T> says "this class is comparable with T (typically itself), and here is how to compare it with T". Let us imagine that our Car class from above actually implements Comparable<Car> like so:
public class Car implements Comparable<Car> {
...
public int CompareTo(final Car that) {
int diff = this.getHorsePowers() - that.getHorsePowers();
if (diff == 0) {
diff = this.getTopSpeed() - that.getTopSpeed();
}
if (diff == 0) {
diff = this.getNumDoors() - that.getNumDoors();
}
if (diff == 0) {
diff = this.getColor().compareTo(that.getColor());
}
return diff;
}
}
In essence it compares Cars first by their horsePower. If they are equal, it compares them by their topSpeed. If they are equal again, it compares them by the number of doors and so on.
Now let's recap: Lambdas are syntactic sugar for implementing interfaces with exactly one method and Comparable<T> describes how a class wants to be compared to T. Now recall what I have said above about Lambdas and states: Lambdas do not have any state. Thus, comparing them with anything is in most situations pointless (no state - nothing to compare; I say "most of the time" since there might be corner cases where such a thing might be feasible). So there is very little reason to actually implement Comparable<T> with a lambda.
In conclusion, we can say that while it is possible to implement Comparable<T> with a lambda, it is seldom useful.
1I know that the comparison lambda would normally writte as Comparator.comparing(Car::getColor), but this is besides the point I am trying to make.