In that case, I would concede to using compareTo() if both operands are instances of Number. Maybe add a Numeric interface if that doesn't suffice. I can't make it use .equals() because this:
aSet.equals( anotherSet )
ends up calling compareTo() on the elements of the Sets if they are Comparable. See the failing listEqualsMethod() in the attached code for an example with Lists. Note that while my compareTo() is contrived to throw an exception, compareTo() can validly throw one when given null or an inappropriate class, while equals() cannot. That can lead to a simple test for List equality (using either .equals() or ==) throwing an exception.
In my real test code, under my control, I have an expected Set of (evil third-party) objects, and an actual Set of objects, and I must compare the Sets. It looks like my only recourse is to manually re-implement Set.equals(). Or to move the tests to Java, losing the power assert.