If an estimate is not a promise then as a product owner how can I deliver my projects without knowing how long it will take?
This is one of the biggest misunderstandings about Scrum. The question of "How long will my project take?" assumes that you can define, at some point in time, exactly what the project will entail in order to complete. But the whole idea about Scrum is that it acknowledges that the things that you learn about a project, as you work on the project, are going to change the definition of the project.
The most common way to define a project is to list the features it will have. Typically, a project is completed when all of the features have been implemented. But what if, as you work on a project, you realize that 5 of the features identified at inception aren't going to be needed, but there's 7 features that people thought of in the first 6 months that really should be included? What does that do to the question of how long it will take?
Another factor is that the things you learn will change your understanding of how to implement certain features, and as you get closer to implementing each feature your estimates are going to change. Personally, I'd resist putting numeric estimates on anything not approaching the horizon of being implemented - maybe using descriptive estimates like "tiny", "small", "medium", "large" and "huge" or "epic". Then you're not implying an accuracy greater than you're capable of estimating.
Truthfully, "How long will it take?", isn't answerable any more than, "What will it be when it's done?". Accountants and traditional business people hate this, which is why it's very hard to move away from Waterfall in some organizations.
It's also why you need to take a lot of the talk about velocity and metrics with a grain of salt. Software projects have a kind of Heisenberg's Uncertainty Principle built into them, and if you spend too much time fine tuning measurements you're just going to end up with extremely precise nonsense.
So no, an estimate isn't a promise. It's an estimate. The "promise" is the commitment the Team makes to complete a certain number of features or stories in a particular Sprint.
The estimates need be just accurate enough to allow the Team to identify how many features (or stories) they can fit into a Sprint snugly. Even more important than accuracy in the estimates is consistency, because the Team will learn how much work worth of estimates they can fit into a Sprint, even if the actual work turns out to be usually twice as much as they estimated. As long as it's consistently off, they'll be able to plan.