Well, user can start transaction anytime, but the fact is that if we think ORM we do not know nothing about the database. we just persist and flush objects.
Yes I think these would be very useful, from how I see it, if you use event listeners, is:
loadClassMetadata: you can apply extra mapping
onFlush: you can modify entity changesets, or persist recalculate new ones, without triggering the database, since it is not used to begin the database modifications yet.
onBeginTransaction: could use the database modifications keeping in sync the entity changesets. the thing about this event is that usually in behavioral way atomic updates are required. for example nestedset tree sync lft rgt columns, sortable sync the sort index, materialized path, all these requires atomic updates, and the best place is the start of transaction.
onCommit: could be useful to execute right before commit, finalizing database modifications could be done.
onRollback: this one is really something, since if you go far, there might be something like files uploaded during the entity processing, and you may want to remove them if transaction fails.
Improvement
Open
Major
onFluish is not the start of a transaction. It has nothing to do with this.