Yes, project managers easily can have that level of comprehension, but it is rare to meet a project manager that understands that a time range is something like a confidence interval. That is, if it is estimated a task will take 3-9 weeks, with some probability (say like 10%) it will take an even shorter or longer amount of time. There is uncertainty encoded in the time range, but the time range itself is also uncertain.

Fundamentally, the problem is that project managers set deadlines based on statistical estimates from developers. Despite the fact that they set the deadline and do not understand the dispersion, they want developers to be responsible for misses. Sometimes, people mistankenly believe that there is some magical practice that can eliminate the uncertainty from estimation. You can make predictions with things like story points and achieve a certain amount of accuracy with a certain amount of dispersion. Statistically, it is the longitudinal behavior that can be predicted (sprint success rate at a specific velocity on a stable team), but we focus on cross sectional details (we missed this sprint).

Project management is generally not considered a field requiring statistical expertise but modeling reality of the work requires it.

Why not just say that then? It’ll take 3-9 weeks. You can then just add all the min and max and get a full range.

No, points mash together size and uncertainty. A task that's "3-9 days" will have fewer points than a task that's "3-9 weeks". And a real that's "3 months give or take a week" will have more points than either.

Of course, there's actually no such thing as a "3 months give or take a week" estimate for a task. It's basically impossible in programming to have a task that takes that long with that low a level of uncertainty. So in reality, time estimates have the same properties as points: the higher a time estimate, the more uncertainty it represents.