As opposed to defining a hash code for everything, yes. Parent asserts that writing obviously-correct comparators is easier.

IDEs have had good equals/hashcode auto-generation mechanisms for years.

Java itself introduced Objects.hash(Object...) in 1.7 https://docs.oracle.com/javase/7/docs/api/java/util/Objects....

It's never really been an issue at all to implement equals/hashcode, which you're required to do for effectively all Collections-based usage anyway.

funny enough, a hash code defines an order on a set

Is it in any sense a useful order though? You can assign any order to any set of objects, but you'd want it to be useful. A hash - the more hash-ey it is, the less the order means AFAICS.

For the purpose of making a tree data structure, all linear orderings would be equally useful. Hashing only provides a partial order, so it's important to choose a hash function that won't assign the same hash to large batches of items.

But it only needs to have this property for hashes of one particular size, whereas a hash map requires a function that behaves well for a variety of hash sizes. So there's an opportunity for using a cheaper hash function.