PO has no time for Product Backlog Management between Review and Planning

However, I understand that these new items should be done in the next sprint, since the DevTeam just worked on these topics and are at their best performance when keeping the focus on the same functionality.

I'm in disagreement with this. As a Product Owner you are empowered to say yes or no when it comes to incorporating feedback from stakeholders into the Product Backlog. There's a balance to this where you want to take their feedback into consideration but always incorporating the feedback immediately may not be what's best for the product long term.  

Is this feedback that you're prioritizing to the top of the list a higher value for the business and customer than what was on the top of the list going into the Sprint Review? 

You may need to practice saying 'yes, and we can incorporate that into a future Sprint' or sometimes just 'no'. The current roadmap, goals, and Product Backlog can work as empirical evidence to back up your stance. 

Let's assume the PB is ordered by value and during the review some stakeholders raise opinions, I as a PO agree partly on but would like to do more research to understand the urgency/importance. Further, the new item needs a bit refinement to be considered ready. However, I understand that these new items should be done in the next sprint, since the DevTeam just worked on these topics and are at their best performance when keeping the focus on the same functionality.

As Product Owner, which do you think would be more valuable: having a team which worked efficiently on the wrong thing, or with less efficiency on the right thing? 

This discussion fits in so nicely with my Agile quote of the week from Peter Drucker:

"There is nothing as useless as doing something efficiently which should not be done at all."

DevTeam just worked on these topics and are at their best performance when keeping the focus on the same functionality.

This seems to be a false premise, or at least an incorrect idea of "best performance".

Although it may be easier for the development team to keep working on the same features, functions, components, or other part of the system, this doesn't equate to best performance. If you measure performance based on the delivery of valuable, working software, then the team is at its best performance when it is working on the work that, when completed, will add the most value to stakeholders.

How do you handle this kind of feedback in the limited time available?

If it needs review and refinement, do so in the upcoming Sprint. If your Sprint length is so long that work presented at a Sprint Review can't be refined and ordered for a future Sprint, then I'd suggest that your Sprints may be too long. Of course, there may be some well-understood feedback that can be presented at Sprint Planning and there may be some critical feedback that is essential to resolve quickly, but work that can't wait should be exceptional and not the rule.

How long are your Sprints? How many Development Teams are working on your Product? And how many members are in each Development Team? Is there flexibility in your organization accepting shorter sprints?

How do you handle this kind of feedback in the limited time available?

When my client gives me the freedom to be creative, I select one week sprints with a Development Team as small as three members. I would rather have two or three Development Teams working on theme-related work (combined work must result in a Done increment), rather than one large Development Team working towards a large Done increment. A one week sprint makes managing the Product Backlog and Product Backlog Refinement easier for me and the Development Team.

Talk to your Scrum Master and your Development Team members. If there is consensus on a shorter sprint, discuss it with the stakeholders. Being open and honest about being overwhelmed could be your first step.

What I haven't seen mentioned here is this. The Scrum Guide says, as the first sentence of the Sprint Review chapter:

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed.

You say:

I as a PO agree partly on but would like to do more research to understand the urgency/importance.

To me, this simply means that your team seem to have trouble achieving the purpose of the Sprint Review.

Given your five options, I think your option 3 is the only one that goes in the right direction, because it's the only one that aims to change that situation you're having trouble with instead of finding workarounds that force a wedge in your Scrum. Getting better at achieving the purpose of the Scrum events is not a waste of time.

Have you tried using retrospectives to discuss adaptations that would help you as a PO to get more out of the review?

Thanks, everyone. The Drucker quote Timothy mentioned and you others refer to hits the nail. As long as we do not know the value it should not be on top. Even when a part of this component has just been done.

It all boils down to what brings the most value to the product/company. For example improved UX/UI can have a big impact, but so might have the other PBI on top. First understand the value and then sort the PB accordingly.

To me, this simply means that your team seem to have trouble achieving the purpose of the Sprint Review.

 I more and more realize, that what we are doing is not Scrum as it misses some key elements in the events.

Your intention to respond to the stakeholders' feedback ASAP, but holding yourself to a high standard regarding understanding and agreeing on the value in order to adapt the Product Backlog for optimal value delivery, is laudable. The fact that you recognize a conflict there is certainly not a problem - it's the start of a solution.

In my opinion, a mature Scrum team should welcome the challenge to improve the delivery of value to your stakeholders. I don't know what your Scrum Master thinks, but I would suggest that you raise exactly this conflict at a retrospective and challenge your team to work with you on a solution.

I more and more realize, that what we are doing is not Scrum as it misses some key elements in the events.

Meh... I don't know. From the limited information you are providing, I would say you're certainly on the right track if you and your team encounter these quandaries and seriously consider them.

Not achieving the purpose of a Scrum event is not the same thing as not doing Scrum. Not working on recognizing and improving it, THAT's not doing Scrum.

Also, what does your Scrum Master say about these situations?