In answer to the over arching question: You don't. There is no need to use other values.
With the release of Sitecore 8, xDB was introduced to the world which included the concept of a Contact (different from a user). In this solution, and because of the way xDB worked in the initial stages, Contacts were being updated and changed through Content Delivery Servers. In a scaled out architecture, it was important to not instantiate a contact on multiple servers for the purposes of writing to. This is where the xDB Contact Locking Mechanism came into play where a Content Delivery server would lock a contact to a session.
However, many use cases existed where obtaining contact information on other servers (CD's and CM's) made sense. Born of this idea was the concept of a Read Only contact.
In a Read Only contact, the ContactSaveMode was set as ReadOnly.
SaveContactToCollectionDb was originally named
SaveContactToxDB. This method has a validation in it to ensure that the contact can be saved. In the event that a Read Only contact is passed in, it would not attempt to save the contact.
Why New Contacts Need It
At the time (as well as now), when a new Contact is created (like anonymous contacts, or contacts not in xConnect/xDB yet) that property is actually not automatically set.
Not setting this property prevents the
SaveContactToCollectionDb from saving the contact to xConnect because the SaveMode is not set.
This is why documentation requires you to save this property with that Enum.
Use Cases for Other Values
Simply put there are none, in a 9 world. In fact, contact locking is no longer a thing. However, there are artifacts in the Sitecore API where old methods and properties were never really updated.
This is one of those areas.
However, Pre-9, this was a common use case when we wanted to get a read only contact. While we never purposefully set this property in code, loading a Read Only contact would set this property as "ReadOnly".