In some companies, "Story Points" have the following two purposes.
A convoluted measure for customer billing, the customer won't really know how much effort has been put up for the said amount of story points in the bill.
A number by which the developer has no idea on how much task he is taking
Essentially, story points are an abstract way to define the complexity of a task at hand, usually denoted in terms of the numbers in the Fibonacci Series (natural numbers are acceptable too). The higher the number, the complex the task; so, if the number is large, it implies that it will have to be broken down into smaller manageable pieces.
Story points was intended to help the developers provide an effort estimate of the tasks without committing to the number of days/hours which is usually hard or not accurate. However, it has turned out in a way that it masks a direct way to calculate the effort that was involved in Time & Material Projects.
It is also to help in building a clear and expressive burnout charts that show how big the tasks were that the team had worked on.
Sometimes, the story points are twisted so much that the stories in them are just made up and the points don't really matter. Another problem with story points is that the management would expect the team to achieve the same amount of story points or more in each sprint, under the name of "increased productivity", even if they are understaffed. On the contrary, the team inflates the story points just to level it with their previous sprints, so that they will not be questioned by the management. Hence, neither the manager nor the team would be able to tell the exact amount of work done. They will have to settle down with the figures knowing each one is cheating the other.
Some interesting dialogues we usually hear on story points.
"The customer won’t agree for that many story points bring it down further…"
"Do the story points include the testing effort?"
"Please move the incomplete story points to the next sprint..."
Excerpt from my book - Excel in IT