If Group is frozen:
VCS will not take any failover action on the group. The Agents will only monitor the resources in the group, will report any state-change and group may be seen as faulted if a resource is faulted. However there will be no failover action for the group.
If the group is frozen persistently, all the above is applicable in a current life of cluster. However, if the cluster was to boot-strap again (ex: hastop -all followed by starting all nodes), the group's state on first probe will be honored. no further actions will be taken - like AutoStart of group.
If System is frozen:
VCS will not choose this node as target for online of any group. However already existing online groups will continue to be online till there is need for it to be failed-over due to user-action (switch/offline) or fault-event.
Temporary frozen system will have this behavior in current life of cluster. However the persistent frozen system will continue this behavior if the cluster was to boot-strap again.
Coming back to the question: For OS patch maintenance - i would suggest to evaluate the following:
1. If the OS maintenance does not impact the the health of applications (VCS and related service groups), then you may just apply the patch.
2. while in maintenance, if you do not want any service groups to be brought online on this particular node - but you need VCS to be running during this time, you would want node to be frozen. You may have evacuated the node by switching all online service groups to other node. If the patch needs reboot and system may not be yet stable after reboot is over, you would not want this node to bring groups online, in this case node should be persistently frozen.
3. If the reboot is required, VCS will evacuate the service groups to the other node. If you do not need the service groups to be evacuated, the persistent freeze of service groups is good idea.