Let's step back a moment and try to look at this from a different perspective.
If your team is using a defect tracking database to track bug backlog, then we should agree that the primary purpose of the defect tracking database is to
- triage new bugs/work as it comes in
- manage the 'triaged' backlog of bugs/work (assign, prioritize, etc the work)
You started by stating "many project managers..." and this is the perspective that you should be approaching the problem from because it is usually the project managers (and hopefully dev and test managers/leads) who are triaging the backlog on a daily (or frequent) basis.
So, the categories you choose should be those that most help the project manager and other managers query on the types of bugs that are most important to them.
Severity is a subjective rating that reflects the negative impact on a customer. Priority (usually assigned by the triage team) is used to indicate how quickly or the order in which the bug/work item should be addressed. But, there are many other ways to slice and dice bugs/work items.
For example, we track test code defects, product code defects, documentation issues, etc in our databases. So, to differentiate between bug types categorize by "issue type."
Other categories we often use for triage include Blocking branch, feature path, milestone or sprint, triage, and status (active, in-work, resolved, closed).
I agree the number of categories should be kept to a minimum. Filling out a lot of unnecessary/unused fields in a dB is often pointless noise and clutters the important information.
IMHO, work with your project manager and understand what types of queries they want to run on the defect tracking database and use that to identify the categories important for your team.