Exactly what I thought you were saying, and disagree with.
I consider it fine to say "Objects require identity",
without identity a fully encapsulated object is nothing more than an anonymous black hole.
When you turn this around to "Only objects require identity", or "identity is not meaningful for data", a hash code is one example of data which could benefit from identity, since you do not want to mix hash codes made by different hash functions. The positive integers 0,1,2... differentiated between the set of nonnegative integers are another simple
to preclude identity from data, is to preclude the ability to differentiate these on anything but the value level.
surely a simplification, but by no means necessary.
Hash functions on values don't depend on identity and collisions are accepted as part of hash's definition. A GUID (and MD 5 hashes) for all practical purposes are identities.
Identities really mess up equational reasoning which is why they are basically missing from pure functional languages like Haskell. A lot of clever solutions like FRP involve solving what are otherwise straightforward problems without resorting to the use of identity.
Apologies I meant the identity of the hash algorithm e.g. MD5, attached to the bits produced by running the hash algorithm on an object, while hash collisions are absolutely accepted, mixing hash values produced by different hash functions is generally frowned upon.
Identity at the structural level is very much either you care about the identity, or you do not (in which case "this one"...), maybe 99.9% of the time "this one" suffices, however the takeaway from this should be that identity of structurally transparent objects should be ignorable, rather than structurally transparent objects should not have identity should one care to acknowledge it.
I didn't make any value judgements about the usefulness of immutable data structures.