I suppose so.

---

"I think I don't understand why object reference is worth a special operator (besides performance reasons)."

The point of "egal" is that you don't have a special operator: you use the same operator for both mutable and immutable objects. It's wart (and Arc/Common Lisp/Scheme) that has a special operator for reference purposes. Just because you call it "addr" rather than "eq" doesn't make it any less of a special operator. And I doubt you put it into wart for performance reasons.

The "egal" article actually defines equality as "operational equivalence":

  Two objects are "operationally equivalent" if and only if there is no way
  that they can be distinguished, using ... primitives other than [equality
  primitives]. It is guaranteed that objects maintain their operational
  identity despite being named by variables or fetched from or stored into
  data structures. [Rees86,6.2]

So my stance is simple: immutable objects should be compared by recursing on their components, like how "iso" works in Arc. Mutable objects should compare by reference equality, because the whole point of mutation is that you can change the object without affecting other objects which have the same subcomponents. That has to do with the conceptual model of how the objects are used and has nothing to do with performance.

The reason the article talks about performance at all is because immutability is much preferred in parellel computing, and most Lisps treat cons cells as immutable, but they're not actually immutable, so the parallel system has to have extra infrastructure to support mutable conses, even though they're almost never mutated. In any case, the point the article is making is valid even if you ignore performance:

  There are a several problems with EQUAL. First, it may diverge in the
  presence of directed cycles (loops) in one of its arguments, although some
  (e.g., [Pacini78]) have suggested more sophisticated predicates capable of
  detecting such cycles. Secondly, it is not referentially transparent; two
  calls to EQUAL on the "same" (i.e., EQ) arguments can produce different
  results at different times. Neither of these possibilities is to be desired
  in a programming language primitive equality test because we would like such
  a test to always return and we would like object identity to be preserved.

  Yet EQUAL is an extremely valuable operation, because the vast majority of
  Lisp lists are side-effect free--i.e., "pure". Without side-effects, loops
  cannot be constructed and sublists cannot be modified, and within these
  restrictions EQUAL becomes a well-defined and useful operation.[8]

  This tension between the simplicity of EQ and the usefulness of EQUAL has
  led to a great deal of confusion. This confusion has now lasted for 30
  years, with additional confusion having been recently added by Common Lisp.
  Since neither EQ nor EQUAL has the desired semantics for the multiplicity of
  Common Lisp datatypes, Common Lisp added six more--EQL, EQUALP, =, CHAR=,
  STRING=, and STRING-EQUAL, yet these also lack the correct semantics.[9]
  Scheme continues this confusion by offering the three predicates (eq?, eqv?
  and equal?) which are roughly equivalent to Common Lisp's EQ, EQL and
  EQUALP.

But with mutable conses, you do need "eq", because two cons cells that are equal may not be eq. So, if your language distinguishes between mutable and immutable conses, you only need "egal". This not only prevents abstraction leaks, but it also preserves operational equivalence, which means that if "egal" says that two objects are equal, then it's impossible to distinguish them in any way. This is not true with eq/equal.

As a practical example of why you would want that... look at Racket. It has three kinds of hash tables: hash-eq, hash-equal, and hash-eqv. And it has all kinds of issues if you use a mutable object as a key in an "equal" hash:

  Caveat concerning mutable keys: If a key in an equal?-based hash table is
  mutated (e.g., a key string is modified with string-set!), then the hash
  table’s behavior for insertion and lookup operations becomes unpredictable.