You need both because severity and priority aren't necessarily set by the same people who have the same information. They're (of course) not completely orthogonal: generally there's a 1:1 map between severities and priorities. I think we're in violent agreement: severity is also a close proxy for how much I think you should care about something. (We don't assign severities to hardening tasks, since they're, well, hardening, not bugs--but there are plenty of hardening tasks that I think are more important than vulnerabilities and should be prioritized sooner. E.g. "unencrypted EBS volume" is a finding I will totally let you ignore, but I will also be on your case every day if you're not using aws-vault.)
So, to rephrase: you need both precisely because that's often the way you can even start having the prioritization conversation.
We're in perfectly peaceful agreement, it's not even violent :-). As I mentioned in my post above:
> Just to be clear, I am absolutely not arguing that severity shouldn't be tracked, I'm arguing against the idea that purely functional customer requirements should be the only criteria used for prioritizing bugfixes and development tasks.
So, to rephrase: you need both precisely because that's often the way you can even start having the prioritization conversation.