
Too often there is a blame game for who has to refine the work. It should be clarified this is a team activity not just the PO.

It is never mentioned in Scrum Guide that only PO who does the refinement activity too ;)

Yup, that is why I suggest clarifying it as a team activity.
The lack of clarity on this point can lead to needless disagreement.
The purpose of refinement is to gain enough knowledge/clarity for the team to be able to deliver within the sprint.
So implicitly it has to be a team activity but it would be useful to make that explicit IMO

Indeed a team activity, but not an additional event. Many times that has been applied as a recurring full team event. So perhaps make sure its clear that it does not require everyone to work on refinament.

Refinement can be conducted during sprint planning, actually it helps the team to focus on the sprint goal by doing refinement only during sprint planning.
It must be the work of everyone in the scrum team, and sometimes subject matter expert from outside can help.
So not totally agree that is a team activity.

I will suggest best practices for refinement. When? Who? What is and what isnt. Will be great to add.

There are two concerns I have with this suggestion:

I have seen it in multiple teams, in multiple organisations, where this is an issue. Granted this tends to be more of an issue in less mature teams and teams where there is a high level of uncertainty and sense of safety.
Agree, it is highly situational.
Though it is for this reason I think having it explicitly called out as a collective accountability is useful.
It is not about saying how or who has to do it every time but more about clearly establishing the team, collectively, are accountable - they need to ensure the right person/people get the work refined in each situation.
To be clear, I am not suggesting an overly prescriptive description of how to refine but instead a clear definition of accountabilities to ensure the whole team understand this is not just something for the PO (or other defined role) to do as a prerequisite to the team being involved as this is a big step back towards waterfall.

I don’t think it is a matter of chaning the “guide” to a “rule book” and then policing it. Insted it is realising that Scrum is about transparency, inspectiion and adaptation.
What Scrum will call for in this situation is for the Scrum Master to make the innefectiveness transparent, then facilitate and inspection of what is happening where people are open, focused, committed, respected and show courage to change for the better. The outcome is to improve the way they go about refinement.
Putting a rule in is meh as it will not solve the empirical nature of Scrum is missed. Scrum is about revealing the things that are not working and then improving it.
So in this case, reveal that it is not working and it should be a team activity. Then improve it. Lets not make the Scrum “GUIDE” a rulebook and follow the essence of empericism.

The current description is vague, but I think it’s a good thing, because there is no one-size-fits-all solution.

I agree with @Brett, refinement is situational and through empiricism the best way of doing it can be discovered.
By mandating how to do it, we will only be creating a new problem that causes it to not work in specific situations.
Adjusting it will solve some problems and create new problems in other situations.
Scrum guide already includes rules. It even uses the word rules in the guide.

It is a matter of well organized team process everybody adds up with their skillset and domain/product know how