Getting the balance right with User Stories between the Product Owner and Dev Team

There's quite a bit going on here.

I am working with a new customer who are trying to bring efficiencies to how the Product Team provide the Development Team with stories for development.

Why is your Product Team providing stories to the Development Team? Stories should represent thing that stakeholders - primarily users, but perhaps other key stakeholders as well - intend to achieve by using the product. They are not created by a Product Owner or a "Product Team" (whoever that is). Once discovered, the story becomes a placeholder for more detailed discussions between the team and the relevant stakeholders.

Currently the Product Owner writes the requirement, these are then reviewed/discussed with the wider Dev team. The Dev team then take them away for an in depth sizing session where story points are awarded, then given back to the PO to either include or remove from the backlog.

There is a lot of back-and-forth or handoffs here. Collaboration between the Product Owner and the Developers would go a long way. Although I recognize the need for Developers to take in the work, especially when they are working through technical details to find dependencies and work out complexity, but the Product Owner represents the external stakeholders and should be involved to make sure that any decomposition or splitting that is happening continues to make sure that Product Backlog Items are valuable to the stakeholders and not purely technical tasks.

Why would anything be removed from the Product Backlog after the Developers refine it? That seems quite wasteful. If the work is low priority, the placeholder can be put low on the Product Backlog. It doesn't need to be refined until later on. Maybe the sizing will affect where on the Product Backlog it goes, but even that seems suspicious - in few cases will size determine value of the work, especially if the work is within the scope of the product. If the work isn't in the scope of the product vision, then it should never be shown to Developers nor should Developers spend their time refining it.

Then if required these are brought into the sprint during the sprint planning.

Work enters the Sprint Planning when it comes up in the Product Backlog. Sometimes, work doesn't even enter the Product Backlog. There are people who advocate for more aggressive trimming or pruning of what is in the Product Backlog, but I believe that electronic tooling has made that less necessary while still allowing the team to focus on what is most important to work on in the next few Sprints.

The problem here is that there is uncertainty about how much information the PO should give on the story and how much long each team should spend on this. There is also uncertainty about the process itself. 

The answers to these questions need to come from the team. The environment may offer some clues. Some development organizations, for example, are far more risk averse than others. These organizations typically spend more time refining things that are likely, based on the current ordering of the Product Backlog to be worked on in the next few Sprints. Other organizations are more risk tolerant and may only refine a Sprint or two's worth of work. There's also an element of predictability. Some organizations deal with a Product Backlog that is frequently changing - the environment is changing rapidly, so the work that is in the Product Backlog or the order of that work is changing rapidly. These organizations find it more difficult to refine too much work because it could quickly become obsolete. There's no one-size-fits-all approach, and probably not even a one-size-fits-many, at least without a better understanding of these contextual details.

The problem here is that there is uncertainty about how much information the PO should give on the story and how much long each team should spend on this. There is also uncertainty about the process itself.  

As indeed there should be. That isn't the issue. The issue is why the team think certainty in such matters can be expected. Scrum is intended for complex challenges where both product and process can exhibit many unknowns.

Refinement is an ongoing collaborative activity through which enough of a consensus is achieved for work to be considered Ready for Sprint Planning. Once the Developers are satisfied that the proposed work can be Done in a Sprint, the purpose of refinement has been satisfied.