Severity is a routing decision
Severity answers what should happen when a rule fires, not how frightening the technique is. The same match is an emergency on one host and noise on another.
Severity gets decided once, when the rule is written, and then argued about forever.
The argument happens because the question is wrong. “How severe is this technique” has no answer without an asset. The same match is an emergency on a domain controller and a Tuesday on a build agent that compiles things all night.
Severity is a routing decision. It answers what should happen when this fires, not how alarming the technique sounds in the abstract. Write it that way and the tiers define themselves: this one wakes somebody, this one waits for the morning queue, this one is recorded and closed without a human ever reading it.
Which is why an estate where everything is medium has no severity at all. It has a field. Medium is what a rule gets when nobody decided what should happen, and a tier that never changes the response is decoration.
The practical version costs one column. Give the rule a base severity, then let asset criticality raise or lower it at match time. The same rule fires on a domain controller and on a lab box and routes to two different places, without you maintaining two rules.
Go and count what fraction of your rules sit at medium. If it is most of them, severity is not doing any work in your programme.
CHECK YOURSELF
The same rule matches on a nightly build agent and on a domain controller. How should severity be set?
SHOW THE ANSWER
By what response the match should trigger on that asset
Why. Severity exists to route work. The same evidence justifies waking somebody at three in the morning for a domain controller and a queue entry for a host that compiles code all night, so one fixed value cannot be right for both. ATT&CK describes what a technique is, not what it means in your estate. Ranking by volume is backwards as well: a noisy rule needs tuning, not demotion.