Reason. I assume you see this behavior because all the node permissions are cached in Drupal, and only updated when (re-)saving a node or rebuilding the permissions.
Workaround. So instead of re-saving all nodes of your group individually, a faster workaround would be to go to admin/reports/status/rebuild and rebuild all permissions at once. This would probably also be the place to hook into for a real bugfix: rebuilding of the group nodes permissions, triggered when saving the group node with a different value in the "Group visibility" field.
(This answer is an educated guess, I didn't test myself so far.)
Redesign discussion. A still better solution would however be a larger rework of the OG permissions system, as discussed in Drupal issue #1122388. See esp. comment #10 there, discussing that the "Group content visibility: use group defaults" value is not that meaningful as it prohibits a use case where one wants the group itself publicly visible, but have its content default to private, and setting that via a fallback to the group setting so that later changes are simple. This scenario (publicly visible group node with private group content nodes) is supported by newer versions of Drupal Commons 7.x-3.x (using OG 7.x-2.7 here), but changing the setting only affects group content nodes added afterwards. So it's not the "fallback to group provided default" we want here, even though the "Group content visibility" field has "use group defaults" as its default value (which is not used though). That could be reported as a bug / improvement request to Drupal Commons.
