TL;DR
None of the parties involved appear to understand the purpose of story points. Your management probably wants to use them as a performance metric or forecasting tool, and your development team is likely resisting a prescriptive process with the likelihood of having points converted to units of time anyway.
Unless your organization fully buys into the value proposition of both estimates (as opposed to fixed targets) and estimating by size (instead of duration), there is little value in using story points at all. Story points have utility, but only when used properly and for their intended purpose.
Don't Report Story Points Completed; Report Value Delivered!
My only argument is that by pointing we can quantify to senior management and other stakeholders how much we have accomplished.
Story points are estimates of complexity, not measures of performance. Likewise, velocity is an estimate of team capacity over time, and has no relationship to the value delivered. Misusing either of these metrics for reporting rather than estimation almost always ends in tears.
If you want to report value, you need to find a better reporting metric. In general, the Product Owner is the person best-placed to determine a given feature's value to the business or its customers. Alternatively, if your Product Owner has used a system like relative weighting to prioritize the Product Backlog, you might consider using either the value or value-minus-cost from the exercise for your reporting needs.
Reasons to Use Story Points
Entire books have been written on this subject. It's worth noting that most agile frameworks don't require estimates in story points; you are certainly free to estimate in ideal hours, dollars allocated, or any other metric that works for your team.
The main reason agile practitioners choose story points over other metrics is that they don't directly measure time. Consider the following:
A key tenet of agile estimating and planning is that we estimate size but derive duration.
— Cohn, Mike (2007-10-03). Agile Estimating and Planning (Kindle Locations 1288-1289). Pearson Education. Kindle Edition.
If you accept this axiom, then measuring in story points would allow you to quickly estimate the relative size of a story. Derivation of time is then usually done at the release planning level (measured in iterations), rather than within iterations where capacity planning is more important.
You can read the extant literature to determine for yourself whether the converse (e.g. attempting to derive iterative capacity or release schedules from per-feature time estimates) is possible, practical, or reliable. Perhaps more importantly, you will have to form your own opinion about whether it is faster or slower to estimate in units of time, and what the trade-offs in overhead vs. accuracy really are.
The prevailing wisdom is that story points takes less time to estimate, and that they lead to more reliable estimates within an iterative framework. The effectiveness of your implementation may vary.