This is how I understand the argument against general availability of EQ: Program Z wishes to run a program P that is designed with capability X in mind, but Z requires that P use capability Y in place of X. If P were able to invoke EQ then it would be able to thwart the intent of Z for P to invoke Y in place of X.

Perhaps I have misstated the problem but it seems clear to me that for P to compare X to Y it must hold X, in which case there is no way that Z can prevent P from using X directly. For Z to prevent P from using X, P must insure that P does not hold X, in which case there is no harm in P holding EQ.

A similar issue arises in invoking a two parameter routine. If the two arguments are mutable (such as an array reference) then whether the two arguments are the same may be relevant to the routine logic and indeed discoverable by the routine without EQ. The routine can discover this even if it is the same array at two distinct addresses as in address map aliasing. In this case everyone is better off if the routine has EQ. In general any routine that takes references to two mutable objects must require that the two are logically disjoint or spell out in great detail the consequences of their being dependent.

In Keykos, EQ serves as the conceptual foundation for synergy which most object systems embrace in some form and under some name. Note that EQ? is seen as too much by some who like synergy, and it is clearly too little as a primitive to actually found synergy; it is too slow.