When to use transactions in Spring with Hibernate?

This seems like a fairly decent answer of why you should. However, this gives some reasons not to. Basically, it you want to use them when data could end up in a bad state if your modifications are not completed.

A good rule is to manage transactions at an application level above DAO. This way, if you have a data access operation A that some times need to be executed in own transaction and sometimes should join the existing transaction, you wouldn't have to jump through the hoops. Combine this approach with managing transactions (and Hibernate sessions) via AOP and watch your code grow more understandable and maintainable.

Using transactions is somewhat dependent on the requirement.

Obviously, using transactions on UPDATE and DELETE operations makes sense. Using transactions on SELECT statements could be useful too if, for example, you needed to lock the record such that another thread/request would not change the read. This would generally be a business requirement.

At our company we do wrap all statements (i.e. SELECT, UPDATE, DELETE) in a transaction.

In addition, transactional management is really better suited at another layer in addition to the data level. Generally, transactions would match the business requirement. For example, if the requirement is to deposit money in an account, then some higher level class/code should be used to mark the entire method as transactional since that specific method needs to be completed as one unit (since there would likely be multiple database calls).

Spring has much to say about transactional management.