Why does the "sn_hr_core.manager" Role grant the "catalog_admin" Role?

[Will West1]

Does anyone know the process reason or technical reason that "sn_hr_core.manager" Role grants "catalog_admin"? These users can create, edit, and delete Catalog Items and User Criteria directly in the production environment which seems risky. This is not constrained to HR Catalog Items but allows these users to create, edit, and delete all Catalog Items including ITSM, WSD, GRC, CSM, etc.

I can understand a highly controlled Role such as "sn_hr_core.admin" granting "catalog_admin" but do not know why the more general "sn_hr_core.manager" Role would need this access and, if they do, why it does not grant a safer Role such as "catalog_editor".

Also, since "catalog_admin" grants "user_criteria_admin", they are also able to create, edit, and delete User Criteria. The result is that a "sn_hr_core.manager" working on Knowledge has a high chance of clicking "New" instead of "Edit" (since they now see a "New" button) resulting in duplicative and/or non-efficiently scripted User Criteria (resulting in performance issues) or modification to existing User Criteria that then impacts other users and the Portal.

The Components installed with Case and Knowledge Management ServiceNow Docs simply states that "sn_hr_core.manager":

Grants access to all HR cases, profiles, secure information.

[Markus Nilsson]

Hi,
I stumbled on quite a few implementations where IT react to why the catalog_admin is added to HR role and hence give access to also editing the IT catalog. 
You most likely want to keep HR to be able to own the HR catalog, the way to solve this would be to remove the role and give access through delegated developer. Then HR will still be able to own/edit the HR catalog but not have access to others.