The advantage is that there is a standard library for implementing efficient unmodifiable �read-only� collections. Just because the Java �crowd� have it doesn�t mean they misuse it (or that they do not understand OO); there are the odd occasions when it is useful to tighten down your interfaces and by creating a �read-only� view e.g. you want to return a list of errors while ensuring that none of your clients modify (add or remove) the underlying list. This can be (efficiently) achieved in Java by wrapping your collection in an unmodifiable list as access �reads-through� to the wrapped collection. 

My understanding is that the common idiom for Smalltalk code is to rather perform a copy of the collection (as was suggested by others), this could be very inefficient but needs to be weighed in versus introducing an unmodifiable collection that breaks the Liskov substitution principle and could potentially have confusing concurrency issues (e.g. unmodifiable collection is �read-through� which means that underlying data structure can be modified which will affect the unmodifiable collection.

On the other hand having a good implementation of persistent data structures in Smalltalk would be interesting to play with�

My 2c

Cheers

Carlo

Still, after stating all of the above, I have used Java�s unmodifiable collections to prevent clients modifying results, especially when I know there is a chain of clients that may process this collection and perhaps modify the collection.