I think you have undersold the benefits of having unit tests. Here are two more reasons to have unit tests: Unit tests document exactly how the author expects the unit to be used. Providing known working examples of use makes it easier for someone else to learn to use that unit. My personal favorite reason is that, when it comes time to revise the unit (if it stays, you will), you have a way of assuring yourself that you have not broken the externally visible behavior. I like this because it helps relieve that knot in my stomach when I have to make changes to old code.
Topic on Talk:Requests for comment/Unit testing
I agree there are many advantages / positive side effects of having unit tests.
My personal favorite advantage to writing unit tests, is discovering bugs when throwing things at units and seeing how it responds. It's not uncommon to commit changes to units during the creation of unit tests (ie. adding return statements to a "set" function).
It also acts a bit as "intensive code review". Writing unit tests (in my opinion) is most strong when done for methods written by someone else (ie. better to have someone else write unit tests for your modules). I don't think it should be a guide line though (it's fine to write your own unit tests), but when you have the chance and are in a team, it's worth considering writing unit tests for each other. That way it's basically an intensive code review, understanding of code base and bug hunt – all three at the same time.