Howdy @Twoods This is the way I deal with policy groups - header policies are your security/threat/important first pass policies. They always go right on top for threat scans/security category blocks etc.
Subsequent policies can be grouped according to your entitlements - My goal is to separate out prod policies from testing policies, lump each in their own policy groups and order them appropriately.

Next, my DLP teams would want access only to the DLP policies, same for SOC/Threat policies, SWG team and SWG policies, NPA etc etc.

Hope this helps

We took the approach of breaking out groups from TEST to PRD. PRD groups are ones that we rely on for actual business and generally are set in stone. These require change tickets for the most part. TEST policies are where we, well, test. They are scoped to a small amount of people (or groups) and can change often while we build them out. Ultimately they would move to PRD. We lump our RBI policies under Web currently.

One thing I dont like is that Header and Footer cannot be renamed. I understand what they are getting at with them but it would be helpful if we could name them something we could internallyt reference that makes more sense.

Valid point - the header footer policies being 'hardcoded' is annoying - Can you DM me the name of your organization and I can open a FR to ask PM to consider providing the ability to edit header footer policy group names

We recently had RBAC v2 enabled and we're trying to walk through how to best break our policies out (we've had CASB for 4-5 years, SWG for just under 2 years, and are testing/expanding our NPA use). 

• how did you determine what to leave in "Default" vs "breaking the policies out to SWG, RBI, CASB, DLP, etc.? 

Any other user experience/best practice/methodology would be great as well! 

@AlfaBane Policy ordering is very important for SWG/CASB inline - hence the recommendation is to position your policies as appropriate.
For example - threat blocks/scans ought to be always at the top and then implement other acceptable policy violation related blocks and then do your DLP/CASB/SWG as needed... RBI can also be at the top. below threats .....
DLP is all about scanning things that CANNOT be blocked and needs inspection...
(objective is to block as much as possible through your SWG policies and if you can't anymore, ensure that you're scanning content to not allow movement of sensitive data..) 
Does this help ?

Do the non-default policy groups i.e. custom policy groups take precedence over default groups. We encountered a scenario whereby I created a new policy group for testing NPA policies. The group is positioned BELOW the Default group, which contains all policies i.e. CASB, AWG, NPA etc provisioned to date. In terms of policy ordering, the custom policy group appears to have taken precedence over the Default group. All NPA traffic was being caught by policies within the custom policy group.