I pretty fundamentally disagree, though of course I don't think your argument is unreasonable for a smaller product.
For companies where products are relatively small and largely disconnected from one another I think your approach can work - senior leadership is largely concerned about maintaining the organization while explicitly delegating product ownership to team leads below.
The problem is that this falls part really quickly once the products reach a certain feature scale, and in fact attempts to do this is IMO responsible for a lot of the product incoherency in a company like Google.
For example, when I was there, there were multiple features that launched on Android Maps but never on iOS Maps. This was an example of shipping the org chart - the Android Maps team came up with the feature and shipped it, and the iOS team was separate and uninvolved.
Of course shipping one's org chart is not an exclusively Google problem and is very common - but it's a fundamental consequence of delegating product ownership downwards. The ownership of the Android and iOS apps were necessarily separate because of the sheer size of these products and their teams, and there is no effective way to coordinate between them.
Sure, theoretically everyone can play nicely and talk to each other and sell each other on how great of a feature it is - but realistically that just doesn't work. The coordination overhead between teams when there is no high-level forcing function is extreme and grinds work to a halt. In reality what you need is a VP or Director-level to say "we need this on both OSes, prioritize shipping this feature on both ends".
And that... definitionally breaks the notion of downward product delegation.