I agree that for small ordered sets (like Handlers/Listender, see example from Javadocs) this is a good idea, but its still the wrong set for this use case:
The listeners on close are registered by code that may (unlikely) come from different threads (e.g. FieldCacheImpl registers an event to purge the caches on IndexReader close, or maybe in future Solr registers a handler - this is generally done on setup of IndexReader). In general synchronization would not really be required at all, but as also different threads may register listeners, there should be some basic synchronization. If you would use CopyOnWriteArraySet, registering/removing new listeners gets slow, as it has to copy the array each time, so registering event handlers will not block but just be slow. On the other hand we have very fast access just for exactly one single iteration on thi set (when the listeners are triggered, on closing the reader). We get this for free without sync, but who cares, IndexReader.close() is the last operation on an IR where you have no concurrency anymore.
I think we should stay with a simply synchronized LinkedHashSet which is cheap as concurrency is no issue at all (not many threads will ever register an event, the whole synchronization is just to guard the set for concurrent modifications (e.g. if two threads create a new FieldCache entry at same time). The addition cost for sync on IR.close() is a no-op, as explained above (no concurrecy anymore).