I quote the docs about UOW:
Sometimes actions on entities span a longer timeframe and / or multiple screens it's then often impossible to start a database transaction as user-interaction during a transaction should be avoided. To track all the changes made and to persist them in one transaction can then be a tedious task. With the UnitOfWork2 class this can be solved. The UnitOfWork2 class lets you collect actions on entities or collections of entities and can perform these actions in one go. The UnitOfWork2 class is serializable which means it can travel accross remoting boundaries. Entities and entity collections added to the UnitOfWork2 class are not aware that they're added to that class, so if you decide not to continue with a given UnitOfWork2 instance you can simply let it get out of scope. UnitOfWork2 objects figure out the order in which actions have to be performed automatically: first Inserts, then Updates and then Deletes. This is controllable, see the section below about
So, you can use transactions if for example you have to perform multiple action in one method and you want atomicity. If the process has more interactions with the user or with the business logic you should go with UOW. For example a multi-step user wizard, or a complicated business logic where you go through multiple methods storing "things to persist".
Internally UOW instantiate and use a transaction as well.
