James,
An excellent set of questions that really focus on understanding the guts of Hibernate.
What helps me the most is to remember what "inverse" means in this context (which means I look it up in
Java Persistence in Hibernate whenever I hit a problem!).
Mapping an association as "inverse" in Hibernate tells the framework that this association is a mirror image of the association on the other side.
When you tell Hibernate a side of an association is inverse=true, you explicitly tell Hibernate *not* to synchronize that end with the database.
This is why, in your example, when you add a notification to your mappings, it doesn't persist the data -- by marking it as inverse="true", you've asked Hibernate to ignore that addition!
The utility is in minimizing/avoiding updates in cases where you want only one end to handle updates, the classic example being adding Bids to an Item in the Caveat Emptor example. You want the Item to handle the cascade of adding and deleting bids; you don't want making a change to Bids to cascade up to the item. This minimizes unnecessary updates, selects, etc.
If the code works fine without inverse, you probably don't need it. If you need to add zipcodes to notifications, and notifications to zip codes, and don't want to force only one method of adding for clarity in your code, don't worry about inverse.