I'm not yet an expert on this, but I'm coming to the same intuition that the writer has so let me attempt to explain.
Let's say we have 4 domains, and 4 domain experts. P is product, B is backend, F is frontend, and D is database(this is heavily simplifying, I know there are many sub-domains within each depending on the scope of the project). Each new feature starts with the P expert working with the team translating the user requirements into what he thinks is needed. B and F communicate with each other. B and D communicate with each other. But since none of them have a shared understanding, the communication is of poor quality. You get mistakes. You'll find that if you had an PF expert the implementation would be 10x simpler. You get things where if you had an PBFD expert would be 1 million times simpler. Without the cross-domain knowledge you will never know when those simplifying measure are possible.
The problem with starting with a P is that the expert is basically starving the rest of the team of the knowledge that they have accumulated. They handle that work, it's up the the product expert to come up with the new features. And by putting that title on their head, and never letting the developers in, it tends to lock in place.
You are only as creative as your feedback loops, and your feedback loops depend on the bandwidth of communication. Within waterfall that might be months. Within agile that is a sprint. But with a PBFD expert your feedback loops can be measured in seconds.
You don't need PBFD experts, but it is very helpful to at least have translators. So there might be a PD expert, there might be a BF expert. That way you can get a reasonable translation of the requirement out. By taking on the team a Product Manager who is explicitly non-technical person, you lock that P in place. I think that's why we're seeing push-back to PM's where it's a general domain issue. P is a fine role, if you also have a PD, if you also have a PB, if you also have a PF. The Fullstack developer is already a BFD, why not also train them in the product?
The example I like to give is that Linus Torvalds created git in 10 days because he was a master user of Source Control and knew exactly what he needed while also able to create everything, while Microsoft's Source Control team had worked with hundreds of developers over years and couldn't compete. When you have hundreds working on a project the ability to communicate in a depth-first-search style drops to 0, and you are left to only breadth-first-search solutions. Metcalfe's Law destroys productivity.