There are different audiences for demos though. It should be that way at the "working level". When you start moving up the chain with more senior leadership in your org, it starts to make more sense to have the PM do the demos/briefs.

Usually devs don't particularly care or want to and sometimes they aren't really qualified to--its not their skillset. But if it's a good PM, that's where they shine. That's the value they bring to the project. They (should) know the politics, landmines, things that specific leaders would care about (and to highlight for them), and how to frame it to current business needs. They have the context to understand when a seemingly innocuous question is actually pointed. They might not know the intricacies of your code, but they (should) know the intricacies of the organization. That's not something most developers know, and why should they? That's not their job.

Sometimes it even involves groundwork meetings and demos to make sure you have support from other key components in your org-- like getting your CTO excited because one of his performance goals was x and your project is the first real implementation of x. Now, you have the CTO ready to speak on your behalf in front of the CIO. As a PM you know that the CIO has been getting flack from the CFO because there hasn't been a good way to capture costs for Y, but your system starts the org down the path to fix that. Now they are both excited about the project and in your corner. Etc etc

How it is where I work. How it should be.

A product owner is not the same as a project manager.