What would be far better is if in sprint planning, tickets were properly split into blockers and improvements (effectively the same as needs vs wants).
Its up to you and your team to help the PM understand what is likely to be completed in a given sprint between the needs and wants and what will rollover to the next (maybe some of those needs are actually wants, and some of those wants are actually needs - this is part of what sprint planning should involve). Part of that is also the PM communicating what needs to get done (and vice versa). Pointing is just a more arbitrary and lengthy means of having that conversation.
Sprint planning is useful, pointing does nothing. If a blocker ticket is in the current sprint there should be a good faith assumption that it will be taken care of. If something happens putting that deliverable at risk, that's where the line 'people over processes' matters more and you have to communicate what issues are preventing the team from completing the blocker.
I guess I'm trying to say. Pointing as a process is a waste of time and the information it conveys can be conveyed more efficiently with good communication with your PM and team and a decent amount of trust between engineering and external teams.
The points are purely to get an indicative size of the work, so it is clear work will be done in the next iteration (e.g. 3 weeks).
If other teams within your organisation need to know when an item is likely to be completed then accurate estimation is useful.
It's a complete waste of time for developers, but unfortunately the rest of the company might need to have an idea how long something might take because they need to sell products or services, and get return on investment.
It's really hard to sell people on "we will do these features/this project, but we have no idea how long it will take so just pay us until it's done". It's much easier to work on your estimations until they always get a little over-estimated, and then sell those estimations to the people paying the bills.