Agile was a small manifesto that listed a set of principles, one of which was "people over processes." If the relationship between your PO and the rest of the team is not collaborative, that's not because Scrum has some dogmatic prescription somewhere in the Scrum bible that declares "though shalt grovel at the feet of your PO and accept their every command without question or suggestion"
If that's how your PO and team behaves, it's because that's how your organization set things up.
Ironically, the relationship described in the article describes "waterfall"; the very boogeyman that Scrum and Agile were a response to.
The role of PO is really just to have a final decision maker as far as how product development gets prioritized and represents THE person to ask when there are unclear product requirements. I mean, at the end of the day when you're trying to ship something, you can't always get everyone sitting down at a table to hash out how the product ought to behave, or whether or not a particular defect is severe enough to block the release.
Also as far as backlog prioritization and delegation goes, you could just as easily target the Scrum Master with the same complaints if your team has one. Although sometimes the PO and SM hats are worn by the same person ... I've seen that at a lot of companies.
I wonder if the article's author would take issue with the concept of a lead developer who has final say on what technical solutions get adopted when there are alternatives (including things like code conventions, 3rd party libraries etc.) because certain lead developers might not collaborate in the way that he thinks all should.