There definitely are cases where that's not enough, but it's a 95-99% solution.
The problems you mentioned:
Classes could change equals to accept subclasses. Then subclasses could not alter equality themselves.
T implementing `equals(other: U)` for some U solves a lot of other use-cases, but could make equality asymetrical.
Reference equality would still exist, but would not be the default, e.g. Java's `equals` is Scala's `==`, and Java's `==` is Scala's `eq` operator (which you almost never use)
This polymorphic equality is the default in some functional languages, like OCaml. It's fine for simple cases, but you really do need overloadable equality. Equality as a method in OO is a problem because of the asymmetry though, and often an even bigger problem because such languages typically permit pervasive null.