Because ==/equals needs to be symmetric to work in collections. Otherwise you add Fraction(10, 1) to a list, and then list.contains(10) may or may not return true. You can’t extend the Int class to be equal to some random class you write.
If you want to have your own number classes, write them all yourself and give them all proper equals implementations, so they may be equal to themselves. For example you could make Fraction(10,1) to be equal to Complex(10, 0) and equal to MyInt(10). But you would need to create that logic yourself.
The Java/Kotlin number classes have no equals cross-compatibility. There is no easy build-in way to test, if for example a double is equal to a long, because the conversion in both directions may be lossy.
But this does not work, because I could never have Complex(10,0) == Fraction(10, 1), because of the wrong compiler error. I can write correct equals but I cannot use ==.
You should also note that + and * should also be symmetric (among other things).
What? Of course you can do that. The compiler error happens because you’re comparing primitive Ints and in that case the compiler knows that you’re doing things that are impossible to work.
That is what one would expect, but you would get a compiler error stating: Operator '==' cannot be applied to 'ComplexPower' and 'ActivePower', in my application. Using equals directly works.
Similarly, Kotlin tests AssertEquals fails but using JUnits AssertEqual works however, apparently because there Kotlins compiler does not do its wrong check.