Consider someone rewrites an algorithm for real numbers to complex numbers
and he relies on the type system to catch all inconsistencies.

The field operations can remain the same, but

(<)

has to be applied to results of

abs

,

realPart

or other functions that yield a real.
The truth of

False < True

relies on the encoding of

False

by 0 and

True

by 1.

However there are also programming languages that represent "true" by -1, because this has bit pattern 1....1.
The CPU has an instruction to fill a byte with the content of a flag
and you can use this bit pattern for bitwise AND and OR operations.
This makes that representation very efficient.
In principle we could also provide machine dependent efficient representations of boolean values in Haskell.

If "true" is associated with -1 then it holds

False > True

.
If you use the numeric value of boolean values for arithmetics like in

2*fromEnum bool -1

in order to map

False

to -1 and

True

to 1 without an

if-then-else

,

then porting a program between different representations of boolean values becomes error-prone.

However you like to work with

Set

s of boolean values and complex numbers,
and

Set

requires an

Ord

instance.
You may consider using the

Ord

instance by

Set

operations an abuse,

since they do not require a particular ordering.

Ordering is only needed for implementation of efficient

Set

operations

and the operations would be as efficient, if the order is reversed or otherwise modified.