The plan usergroup assignment under the Access tab adds that usergroup if they don't have it on plan activation and on plan deactivation should take it away. A plan can only control 1 usergroup at a time. For example if Plan A gives Group A and Plan B gives Group B and they upgrade from Plan A to Plan B they will lose Group A in favor of Group B since Plan A just deactivated.

CBSubs will not touch a usergroup it is not configured to assign. So if Registered is the new usergroup for new registrations as per User > Options configuration and no plan is configured to assign Registered they should always have Registered usergroup.

If you need finer controls of usergroup assignment you will need to use CB Auto Actions with the below in a Usergroup action.

Plan Active
Global
Triggers: onCPayUserStateChange
User: Automatic
Access: Everybody
Conditions (custom value conditions)
1: [var3] Equal To PLAN_ID_HERE
2: [var2] Equal To A

Plan Expired
Global
Triggers: onCPayUserStateChange
User: Automatic
Access: Everybody
Conditions (custom value conditions)
1: [var3] Equal To PLAN_ID_HERE
2: [var2] Not Equal To A

Replace PLAN_ID_HERE with the ID of the plan you want this to act on.

Do any recent subscriptions have this issue? It's possible older subscriptions could be subject to a bug long fixed as there were issues with usergroup assignment in the past. As for clean-up you could use the batch tools in CB > User Management to mass change usergroups for selected users.

CBSubs Settings need to be saved after changing that parameter. It generates a key for the URL and stores it for verification. Once settings have been saved the URL should work fine as long as "Mass expire subscriptions method" is set to allow CRON. In your case I recommend setting it to "Cron task and admin access (100 max/page) " and setting up a wget CRON task to run daily on "Url of cron task" URL.