Sometimes importance is related to size. Points are arbitrary, but lets assume that on average a developer will work the entire sprint on an 8 point task. The PM might decide that feature is not worth the time investment in that sprint, if they could instead get 2 smaller features out the door, or some bug fixed - they might prefer to deliver that to stakeholders.
That's why there's even a velocity expressed in points, like the tasks - it's the PM's budget to work with. So 5 points or 8 doesn't change the work you have to do as an engineer, but it changes the number of things a PM will put on the team's plate in the next sprint, and the points force them to make trade-offs, otherwise they'll insist that the bug, the small feature and the large feature are all high priority and have to be delivered in the next sprint.
I'm not justifying the 15 minute time investment for sizing, that is clearly way too much time, I'm only highlighting that in scrum, as an engineer, you don't necessarily know or decide what the next most important thing to work on is. That's the PM's job.