This is a standard confusion I've always had with the concept of story points. I've always been told that the complexity of story points should go up roughly exponentially. Essentially a task pointed at 5 should be more then 5 times as complex as a task pointed at 1.
However, when tasks are assigned the discussion of story points assigned to a developer often seem to treat the story points as if they are linear. For instance when deciding who to assign a new 5 point ticket to I've had managers say they should assign it to whoever has the fewest points without further consideration. I've also had managers who stated they expected a specific number of points to be completed by each developer per sprint. These approaches, that look at total points assigned only, don't seem to consider the exponential increase in complexity higher pointed tickets may represent.
For example if I was assigned 21 1 point tickets I could theoretically complete them all in a week, but I would never be able to complete a 21 point ticket in a single week. A manager setting an expectation of developers completing 21 points in a sprint because he saw me doing 21 1 point tickets would be setting an unmanageable expectation to my colleague who is assigned the 21 point ticket.
With my favorite teams this was not too much of a problem, we recognized the difference and would assign more points to someone who had small 1 & 2 point tickets, and try to avoid much tasking to anyone taking larger pointed tickets, but these were smaller teams managed by the actual developers with little management oversight and generally a more flexible (one may even say agile) approach to tasking in general, we used Jira to assist our team in assigning tickets and tracking tasks but not for metrics, velocity, or any of those concepts.
On teams where management was trying to collect statistics, velocity, etc from jira and tried to force a more rigorous approach to story pointing I've always felt that the points were inaccurately utilized. In the worst case I've seen management expressing dissatisfaction for members who didn't meet a sufficient number of story points in a sprint without considering the type of tickets assigned to the developer, which penalized taking high pointed tickets and encouraged taking quick bug fix tasks to pad out number of story point's completed.
What is the 'proper' approach for handling story points from a management perspective? Can work assigned to a developer be measured by total points assigned in a meaningful manner? How does one avoid penalizing developers who take more complex tickets?