Story points are fine for collaboration and revealing assumptions. Story pointing and planning poker together will encourage even more conversations around product backlog items (PBIs). The problem with story points happens when they are used for predicting (estimating) schedules, as in velocity. Driving conversations around assumptions and estimating work are fundamentally different tasks.
The primary benefit of story points is to hold discussions on complexity, risk, and unknowns, none of which can be confidently translated into effort and time. There's just not a good correlation and you can find plenty of evidence by searching for "story point hours correlation."
Unfortunately, story pointing has become the de facto way to estimate, and in many cases, story-pointing sessions omit discussions in favor of just coming up with a number used to predict schedules. In fact, agile teams often reassess story points with partially completed PBIs at the end of a sprint or spend a significant amount of time determining points when multiple skills (e.g., testing and development) will be engaged in a PBI: time better spent creating a product increment, not arguing over points.
In an attempt to return us to a more sensible technique, I've seen many people say we should just eliminate story points altogether or use a non-numeric value for points. These approaches will remove the temptation to use story points for predicting schedules, but completely removing story pointing will remove a tool that can foster discussions (of course you can use other techniques to converse). Numbers, as long as they only refer to categories, are generally more convenient than symbols.
There is an alternative to help with forecasting
If you stop using story points for forecasting schedules, you need something else – no forecasting whatsoever is a pretty risky business approach. Flow metrics and right-sizing PBIs work together to give you a better (yet imperfect) estimate will much less effort. Cycle Time, Throughput, and Monte Carlo simulations are the way to go.
Here are my recommendations: use story points and planning poker to iron out PBI assumptions. Then forget the numbers and refine PBIs until the team feels the top few are small enough to fit into a sprint; I typically see around 15 PBIs per sprint as a general observation. Then apply your history to figure out how many raw PBIs you can consume in a particular period. Forecast with a time, but include a probability on that time. For example, saying," I can complete 30 PBIs in the next sprint with 50% probability, 21 with an 85% probability, and 14 with a 95% probability based on history," will make the imprecise nature of estimation transparent and put the risk back into the hands of those who depend on dates.
Learn more
If you want to learn how to use the metrics, search scrum.org’s site for Kanban, or read any of Daniel Vicanti’s work on forecasting or anything by Yuval Yeret (https://www.scrum.org/resources/blog/4-key-flow-metrics-and-how-use-them-scrums-events). Explaining the details here is beyond the scope, but the concepts are not hard to learn if you're willing to put in a little time.
See my classes at www.suscheck.com