What you are feeling is normal whenever a new team starts off or you enter a team freshly.
The current (2020) version of the Scrum Guide does not even mention story points or effort anymore; the closest it gets to this topic is a short blurb in the Sprint Planning section:
Selecting how much can be completed within a Sprint may be
challenging. However, the more the Developers know about their past
performance, their upcoming capacity, and their Definition of Done,
the more confident they will be in their Sprint forecasts.
IIRC, this was different in the past. When I did my Scrum Master certification many years ago, there definitely was some talk about story points, we got our Planning Poker cards and much was talked about how to achieve an actual number for each story. I do remember that much importance was placed on the fact that the story points are not to be directly scaled to effort (i.e., time or money), but it was unclear what they are, then.
In every Scrum or otherwise Agile (i.e., kanban, scrumban, zombie-scrum, scrum-but, ...) project I ever was involved in, the teams used another methodology and scale for the effort for each story. T-Shirt sizes, fibonacci numbers, etc. There is no magic behind this. For me, the only significance of the fibonacci numbers is that they reduce the amount of numbers to pick, i.e. removes discussions of whether the story is "worth" 11 or 12 points, while being a little more granular than straight exponential numbers 2, 4, 8, 16, 32...
At the end of the day, it does not matter. After a few sprints, each team member has a mental image of what the numbers mean. In one of my current projects, we think that 13 or 15 points is roughly the amount of work one member can do per sprint; we avoid having any stories with more than 8 points (if we think they are larger, we split them down into several smaller ones). In other projects we use S, M, L, XL with no particular mapping to actual time.
The Agile Manifesto mentions effort, time, money or story points not at all and also may serve as an inspiration why this may be so in an agile context.
There is no particularly useful way to convert story points to the other dimensions you mention (volume, risk, complexity...), it is perfectly fine to leave it slightly nebulous. If your PO or someone else happens to be a PL in disguise, he is free to divide the cost of the team in man-hours/money by the velocity to arrive at a €/point rate if it makes them happy, but these kinds of discussions better not take place where any of the team members hear it as it only confuses matter and is a step back to the "good old" pre-agile times.
TLDR: by experience, a team expresses the difficulty or complexity of a task with story points. A possible point of having story points is to get a rough measure of whether a sprint backlog is reasonable given the capacity in that sprint; and for the team to communicate these things back to the product owner without bogging anyone down with time or money. It's not that important, considering the official Scrum Guide has all but removed them altogether from its central pamphlet and the Agile Manifesto and other more pure agile schemes try hard to get these things out of the process.