Not pointing story points for Bugs but still setting a priority

My business leaders say that it has been set that way because bugs give no business value

Why would they decide on estimates, when they are not doing the work?

Are they doing it "all wrong"?

Scrum doesn't mandate any particular unit of estimation or sizing. In fact, the 2020 revision of the Scrum Guide removed references to estimation entirely. While the notion of sizing remains as an attribute of a Product Backlog Item that can be determined by refinement, the attributes that are used are determined by the domain. That is, a team using Scrum as the framework for their development methodology doesn't need to formally estimate or size a Product Backlog Item at all.

The only rule that Scrum has regarding the sizing of Product Backlog Items is that a Product Backlog Item is "deemed ready for selection in a Sprint Planning event" when the Product Backlog Item "can be Done by the Scrum Team within one Sprint".

I'd want to answer the following questions:

• Is the Scrum Team able to effectively plan a Sprint? In other words, can the Scrum Team craft a Sprint Goal, select appropriate Product Backlog Items, and develop enough of a plan at the Sprint Planning event to give confidence that they will be able to achieve their Sprint Goal?
• Can the Scrum Team regularly achieve their Sprint Goal, Sprint-over-Sprint?
• Who is the audience of the story point estimates? What does a story point mean to the team and to anyone else who looks at them?

There may be some antipatterns at play. Equating story points to time is a common antipattern. Using story points to compare teams is also an antipattern. These antipatterns may require some attention, but they may also not be a pressing concern if the Scrum Team is able to deliver value on a regular, predictable cadence of at least once per Sprint.

Once you learn more details about what is going on, you can start to understand what the problems are and help the team solve them. Avoid the temptation to change things that aren't problems or spend time on low-impact changes.

While I had experienced the somewhat similar situation following few items helped us to stream line this process 

1: When we identify a bug from previous Stories was it part of acceptance criteria? If so story will not be marked as DONE unless negotiated with PO and and increment meets DOD and obviously the Increment must be usable/releasable. Any extra enhancement/fixing could be taken as new story with estimation from dev team.

2: we also made some ways of working to include high severity issues to be fixed as part of same story and kept minor issues to be considered as open known bugs to address later.

My business leaders say that it has been set that way because bugs give no business value

Story points do not indicate business value either. But as pointed out they may help with forecasting during Sprint Planning, as well as help the Product Owner make tradeoffs between Product Backlog items.

I often see debates on whether bugs should be 'pointed' or not. There's no black and white answer, and the answer depends on the context. Take it to the Scrum Team and allow them to self-manage and find what works best for them. A Scrum Master’s job is not to decide whether to point a bug or not, but rather assist the team in discovering what is right for them. Rather than imposing any solutions on a Scrum Team, a Scrum Master will facilitate positive discussions focused on outcomes. Sure you can eventually give some ideas and teach them. But if you directly give them the solution you may also be impeding self-management just as the leaders are doing in this case.

Did you ever consider that you have been pointing stories wrong the whole time?  And who decides what the right way is to do pointing?  @Thomas Owens and @Ian Mitchell have some great feedback.  You'd do well if you could apply it to your thinking.  Notice I said "your thinking" and not to the team.  I honestly feel that the problem is you and not the rest of the organization.  You seem set on changing the way your new organization works to match what worked for your past organizations without trying to understand why the current organization has chosen to work as it does. 

Just because something is different from how you have done things in the past, doesn't mean it is wrong.