They're both measures of importance, but evaluated at different times by different parties. In the article's formulation, the QA engineer sets the severity during the initial investigation based on technical criteria. This is then one of the datapoints that the PM uses during triage to set the priority, which is the controlling value from that point in the process onward.
I guess the underlying source of confusion is that they're both measures of severity, but priority is severity from business viewpoint while severity is severity from the affected user's viewpoint.
A high priority bug that isn't fixed presumably has severe consequences for business (or it was prioritized wrong).
A high severity bug that isn't prioritized presumably has low consequences (severity) for business, but it probably really sucks for the unfortunate user who is affected.
Here in pivotal-tracker-land the product manager controls priority by ordering stories in the backlog. There is no need for a separate 'priority' field because that is implicit.
FWIW, there's also no explicit 'severity' field; the PM is expected to understand all the factors that make issues important and order the backlog appropriately. If you need more categorization, you can apply arbitrary labels.
