There's a perfectly healthy middle ground where POs are the gateway to new tasks but don't isolate the developers from the rest of the organization, nor disregard developer input.

And since we're talking about Scrum, PO and Developers (traditionally) supposed to sit together with stakeholders for Review meetings, gather feedback from them and provide input on the next tasks.

What works depends heavily on the circumstances and the team (people first). What is to be accomplished: software delivery, operational quality and/or user/customer interactions? Are the responsibility boundaries clear or not? When overall structure is clearer, it is more straightforward to decide who are the best decisionmakers for the team..

What works for one team, might not for another. It's a good idea to have semi-stable teams as there is significant overhead creating temporary teams and disbanding them.

When there's no true need of urgency or the deadlines are outright fake, kanban and maturity may make a good alternative to scrum/sprints. It may even allow for some flexibility how to allocate people and borrow temporarily from other teams. You don't want teams to silo down, which they do the minute they are formed to start healing the wounds. Teams will need clear responsibility boundaries to be able to make effective decisions, while also granted the slack, incentives and psychological safe learning environment that fuel the necessary and logically next steps.