Let's be serious, people don't usually care how you do estimates. What they care about is how much it takes and/or how much it costs. Time and money. That's what they want. The estimates is just something that helps you answer those questions. It doesn't matter what you use for estimations as long as people can get back a time or money value. It can be estimating directly in hours, or man days, or it can be story points, T-shirt sizes, puppies or vegetables. Nobody cares. Seriously now. It's about time and money.
So you need to have a way to convert from an estimation to time and money, right?
Everyone understands what time is. Everyone understands what money is. And we like to think about them as absolute. One hour is one hour. Ten bucks is ten bucks. But not really. They mean different things to different people. If I am rich and you are poor, ten dollars for me might be useless but for you might be difference in having food on the table or not. If I am a busy person and you are not, then one hour for me means a lot and I use it wisely, while for you it might mean spending it online whatching cat videos on YouTube. Although we perceive them as absolutes, they are not.
From the discussions on the other answers I see that you are asking why not estimate in hours directly instead of story points, since story points are abstract and not absolutes. Everyone understands one hour, but story points mean different things for different people, right? But from what I said above, you see story points are not so different than hours. They mean different things for different people. One hour of development for a senior developer doesn't mean the same thing as one hour of development for a junior developer. The senior can build an entire feature in one hour, the junior might use that hour to figure out how exactly to approach the feature. If the senior developer estimates a feature to take one hour, that estimation is subjective. It depends a lot on skills. The senior will build feature F in one hour, but the junior might take four hours to build the same feature. So what good is a one hour estimate for feature F if it will have to be the junior who needs to work on it? (if the senior developer is unavailable for example).
Estimating in hours is a way to lie to yourself and give you false confidence. You understand hours, so when you estimate a project and get back 1078.65 hours then you have some absolute information there, right? You know what you are dealing with. But you don't. Software development doesn't work like that. That's why we are no longer doing Waterfall all over the place but instead trying to be more Agile. There is a lot of complexity in building software, there is a lot of effort that goes into building the right thing, and a lot of risks. Hour estimations don't reflect these and thinking hours are absolutes is simply delusional. History has shown us that. People suck at estimating, and they suck at attaching hours to those estimates. But it seems we can better estimate things relative to each other. If you have two features, you can estimate pretty well which one is larger than the other, thus which one will need more effort or take more time.
Story points are a way to highlight the difference in sizes between features. A 5 SP feature is more than a 3 SP feature, and less than a 8 SP feature. People might not agree that one hour or ten dollars are the same for everyone because a lot of subjective things influence that, but they can agree that one feature is more complex than another. A 5 SP story is a 5 SP story for both the senior developer and the junior developer. It might take the senior one hour, and the junior four hours to build it, but that doesn't change the fact that in relation to the things they both worked on so far, this is a 5.
Initially people have different understandings about what a 5 is. The senior might think 5 is easy, the junior might think 5 is hard. So when estimating you will get different values for the same feature. But there is a discussion. People dissect the feature and explain why they think it's a 5 or a 1 or a 13 or whatever. In time they figure out, relative to the other features, what is a 5 and a 1 and a 13. It doesn't matter how they subjectively reached that number, relatively speaking they learn to attach the same numbers to similar sized features. Once this happens people will know how much to pull into the sprint and the velocity will start to become relevant. Then you can attach hours to the story points per team as you know how much they can deliver per sprint. But just remember that it will still not be an absolute. There isn't a coincidence why you use Fibonacci to estimate. The higher the SPs, the higher the unknown. In fact, it's not even Fibonacci. A Fibonacci sequence is 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, but most planning poker cards are 1, 2, 3, 5, 8, 13, 20, 40, 100. Things get rounded of. The number 89 is absolute, 100 is an approximation. Does it really matter it's an 89 or a 90 or a 95? It makes no difference. It's a lot. So just say 100 and call it a day.
Enough rambling... to get back to your question. The definition of a SP is that it's an abstract measure for the difficulty of a feature and the effort needed to build it. With time, the people in the team figure out what SPs mean for them (this is why, for example, you can't compare story points of one team with the story points of another; 10 SP in one team might mean 40 SPs in another).
See also if this provides extra insight: Why use story points instead of hours for estimating?