I think it might help to keep in mind the difference between how a transaction is actually implemented, versus how transactional state is represented.
Transactions are kept track of in relation to the
thread of execution, but the UserTransaction object isn't itself some objectified transaction. It is only a hook to give you access to transaction information. Its behaviour is very much like the java.lang.Thread class, in that some of its methods do stuff in a way that is associated with your current thread, not with an object reference. By making it an object instead of a class with static methods, the container vendor remains free to implement UserTransaction in whatever way they think is best.
So if you have code like:
UserTransaction trans=context.getUserTransaction();
trans.begin
...
you haven't caused some transaction referenced by 'trans' to begin. You've caused a new transaction to be created, begun, and be bound to your current thread of execution.
So the point of getting the UserTransaction object is to get something that will allow you to create a transaction or query the status of any pre-existing transaction.
As to why you'd want to create a transaction in ejbPassivate, I'd agree that it is a pretty esoteric situation, but at least conceptually you might want to do stuff like write some information to a database (something that would help you recover your state during ejbActivate) and/or toss some messages to a JMS queue. If it made sense to bundle multiple things within a transaction to ensure that they all commit or all rollback together, then you'd need to create a transaction for that.