Sharing rules as additive record access
Key Takeaway
Sharing rules only add access on top of the org-wide default. To remove access that a permissive default gives, make the default more restrictive, such as Private. Then use sharing rules to give access back to the users who still need it.
A sharing rule is an automatic exception to an object's org-wide default that opens up record access for chosen groups of users. You can use sharing rules when the default is Private or Public Read Only. Sharing rules are additive, which means they give particular users more access than the default but can't take access away or make it stricter. So when a scenario calls for less access, the setting to change is the org-wide default.
Sharing rules only add access
Org-wide defaults set a relatively restrictive baseline for each object. A sharing rule makes an automatic exception to that baseline for selected users, so it can only add access. Like the role hierarchy, a sharing rule can never be stricter than the org-wide default.
To create sharing rules for an object, its org-wide default must be Public Read Only or Private. So you can't create sharing rules for an object while its default is Public Read/Write.
When several sharing rules give one user different access to the same record, the user gets the most permissive level.
Ana is in the Support Leads public group and the West Region role. One account sharing rule gives Support Leads Read-Only access to an account. Another rule gives West Region Read/Write access to the same account. Ana gets Read/Write, because a Read-Only rule doesn't lower access that a Read/Write rule already grants.