We (me and my company colleagues) were also very surprised realizing that an important functionality of SonarQube was removed.
Why overwriting the severity and categorizing are important to us?
You are defining the rules and we try to use them all. But we do not always agree. Some times we faced rules which do not align our experiences.
So, in the past we decided either to disable the rule or to reduce the severity. The latter one we use for rule which we like at all but which are too restrictive. Now, we only have a binary decision: use or do not use. 
We have a lot of project with a long history. They were existing before SonarQube was available…
To find a good balance between “clean code” and “effort to handle more than 20K issues” we decided to introduce different profiles according to the combination of type and severity:
Basic: Blocker and Critical Bugs, plus Blocker Issues
Advanced: Critical and Major Bugs and Issues
Full: (Nearly) all rules
With the planned change we only have available the “new severity”. Using this we would get a complete new set of rules for “Basic” and “Advanced”. I do not know how to communicate this to our users!
I value your attempt to revise the rule categories, but please ask users before introducing such big change. At the moment I really does not catch why the new limited categories are better than the old one.
The only problem I faced in the past was the mapping the C# compiler issue levels where only “none”, “info”, “warning” and “error” are available which does not align to the SQ severities.