In your first example you are correct that JPA is hanging on to the updates until it absolutely has to flush
them. In the second example it has to flush them so that the select is working on up-to-date data.
One advantage of optimistic locking is that the database doesn't have to lock any tables. This allows your database to scale better because more clients can issue statements against it. The disadvantage is that it moves much of that concurrency control into the application layer.
This means that you will be required to implement the error handling or retry logic. In the case where you expect no contentious updates this can be good. In the case where you expect many clients to be updating the same JPA entities at the same time it can require a fair amount of application logic to handle the errors and intelligently retry the update without resorting to a "last-write-wins" situation.
You may find this blog post interesting https://blogs.oracle.com/carolmcdonald/entry/jpa_2_0_concurrency_and