There isn't really a great deal to document - it's a very simple interface and if you have a stateless application you may want to use caching to prevent constantly hitting the database.
I think the comment about immutability was probably just Ben being cautious when the code was first written. Obviously the object may be accessed from multiple threads and you might run into issues with ConcurrentModificationException if you updated the authorities list while iterating over it in another thread. These are standard threading issues though. There isn't anything in the framework which I'm aware of which would require that the object be immutable but it usually makes sense to program with immutable objects if you can. Your code will be much more robust. There may be some applications where the end users are able to edit velocity or freemarker templates (or even JSPs). Making the classes immutable also makes them less prone to being modified through technologies like these. But ultimately it's up to you to be fully aware of these possibilities and cater for them.
I disagree that issues such as integration with Hibernate and its caching mechanisms are "very very basic" questions which should be in the documentation. Spring Security has nothing to say about whether you use Hibernate (or indeed any other ORM technology, object database or whatever). It just provides the interfaces and if you choose to implement them using Hibernate then its up to you to understand fully how Hibernate behaves.
I'll update the Javadocs of the UserDetails class to state that immutability is advised but not essential.