It depends on processes implemented at your organization.
If your organization has classic Scrum (or Scaled Agile Framework – SAF) Product Owner role – it boils down to a having a single point of reference when it comes to product development. Product Owner (PO) is a face, heart and a brain of the product team. Business goes to PO to learn deliverables, timelines and resource allocation as PO is responsible for product backlog (and parts of program backlog in SAF). Speaking from experience being a PO – it’s a high visibility role that comes with some perks (you get to talk and influence some highly placed decision makers that would not be accessible in an old-fashion environment).
What I also found helpful while being in PO role is to sometimes take “one against all” stance to present a solution for a business requirement to scrum team and have them poke holes in it and offer better approaches. This is both a great way to engage team (especially a newly formed team) in finding the best solution given current requirements and a good team-building exercise. Without it, I have found the team to be less proactive and not as cohesive (everyone would offer and defend their own solution thus fragmenting overall approach).
It does, however, come with the same high-level responsibility and in case of failure it will be way more prominent (again, because you are exposed to high-level decision makers). It also presents business with a single point of failure in case PO becomes unavailable (time off, sickness, moving on to another job, etc). Immediately a product expertise, leadership, and vision become unavailable and the team loses focus without direction. This is usually remedied by delegating and training other team members to act as substitute/replacement when PO is unavailable. Personally, I found it very hard to schedule any significant vacation time because my presence was required daily to resolve issues (especially with high-level decision makers).
If your organization is not “agile enough” – i.e. has not progressed to implement agile processes far enough for PO to fully assume all responsibilities (you can read about them all here and here) then product owner(s) act more in either business analyst capacity or team lead capacity, depending on which responsibility the given team is short on. In several cases, while being PO I was acting strictly as team manager (without being subject matter expert and having product vision) or Business Analyst (without leadership responsibilities), sometimes at the same time while acting as PO on 2 different teams. In such cases, PO is just a moniker for someone who doesn’t have high enough rank in old matrix organization but who assumes responsibilities missing from the team. The “pro” here is that PO plugs in organizational holes and takes responsibilities that otherwise would have to be taken by higher-ups and usually managed lousy due to lack of interest from said higher-ups.
The cons are pretty obvious – you’re not formally holding any title and you can’t really push your agenda since you almost always negotiate from a position of weakness (being a lower rank than almost anyone else you need a commitment from).
Additionally, PO ends up checking all decision (even small ones) with management (usually not readily available) which tends to drag product development forever. In this case having a PO actually introduces one more middleman between the team and decision makers.
It’s also high risk/high reward kind of proposition because you’re low enough on matrix ladder to be easily sacrificed if your manager feels you’re failing and wants to protect himself but if you perform well you get a lot of respect from people way above your manager (and your management will cut you a lot of slack while you’re in good graces with their superiors).
And, of course, if PO is removed from their role (for whatever reason – moving on or moved out) the product/team will be back to square one – with the same gaps/holes in the structure.