How reliable is velocity?
To give an analogy, it's just as reliable as the weather.
Yesterday's weather, for example, is a Scrum pattern that helps teams quickly calculate how many story points they will likely manage to get done in the next Sprint. It relies on the idea that if you have a stable team and a stable working environment, what you will manage to finish this sprint will most likely be something like what you did last sprint (usually an average of the last 3 sprints is used). If you average, say 100 story points each Sprint, it's safe to say that you will pretty much do something similar next Sprint also. If the team all of a sudden decides that they will do 200 story points this sprint, all other things remaining the same, you can safely bet they will fail.
Just like the weather though, you can only make this prediction on the short term, not the long term. With the weather you can predict with certain accuracy what the weather will be like tomorrow, or this week, but you cannot predict the weather six months from now because a lot of things can change between now and then, you don't have enough information to actually measure things out, etc. And it's the same with predicting delivery dates for software.
In Scrum you work from a Backlog. This Backlog gets continuously refined as new information is learned about the product, as feedback is received, as market conditions change, etc. For this reason you work on the top of the backlog, i.e. the most important things first. The top of the backlog is also more detailed and better estimated than the rest of the backlog. So if you want to estimate delivery dates on the full product, you need to have fairly stable teams, stable working conditions, market conditions remaining the same, no new information discovered or feedback received that could change the rules of the game, and detailed estimates for all the items in the backlog. When these remain stable, you can divide the total number of story points in the backlog to the team's velocity and figure out, on average, how many sprints you might need, then knowing a sprint is (often) two weeks, you can determine a delivery date for your product. In theory.
In practice thou, as I mentioned above, a lot of things change. Your team capacity might change (people get sick, leave, join, etc), market conditions might change, someone discovers some great opportunity and adds to the backlog, some items become redundant, etc. Every time these things change, your calculations involving velocity need to be redone because the target product changes. The velocity itself can also change as the team becomes better at their work, or new team members are added, or older ones leave, etc.
So, although velocity can be a good indicator on how many sprints you might need to finish all of your backlog items (which define the full product, if you like to think about it like that), it doesn't really guarantee you anything. Just like the weather. You have a good confidence level for predicting the weather in the next few days, but not for the next few months.