The Fibonacci sequence is to assist developers with project estimates. The concern is that we consistently see management use the points derived from Fibonacci sequence estimates to determine project velocity, or more importantly - developer efficiency. Which makes obvious sense to do considering that the point of any given project estimate methodology is to, well, estimate the velocity and remark on the trends.
The problem here becomes evident when you consider that a developer could easily demonstrate in one two-week sprint that they crushed 16 points worth of 1-to-2 point backlogs/tasks and then reasonably take two sprints on a single 8-point task. Now that developer has to defend herself as to why her velocity has dropped 400%.
Well she should get better at project estimates.
That's irrelevant. Considering the whole point of the Fibonacci scale is to provide some sense of exponential effort between tasks, a 1-point task vs an 8-point tasks is an 800% difference. In the case above, the developer actually underestimated but management quantitatively sees a dip in performance.
Then the team needs to define what the different points mean.
The only concrete definition a team could come to a consensus on is how much time a 1-point tasks takes vs an 8-point task but if we start trying to put time frames on it, we're defeating the purpose of this agile project estimate methodology; we might as well refer back to flat time estimates.
Well then management needs to understand that the points are exponential and that 16 points achieved in one sprint compared to 8 points in another sprint doesn't necessarily mean velocity went down.
Then why are we going through the trouble of measuring velocity if it's so relative anyways? If we're going to make management understand the complexity of each task that happened in the sprints, then why even use a point system that is consistently used to measure velocity? To be safe, why wont developers start overestimating their points so they cash in more points per sprint? All of these what-ifs and "it depends" doesn't sound very agile.