Should there be different flavors of Product Owners in large products?

An interesting realization I came to.
Maybe this is a very obvious, Scrum 101 understanding for someone... But I think this may actually be helpful for some, so here it is.

In a large-scale product, with different teams working on different tiers, there should be 2, or even 3 types of Product Owners (POs).
"Wow!" - an experienced Agilist would exclaim. "Hold your horses! Are you talking about giving up on the idea of cross-functional, feature-oriented teams (as opposed to architectural layer-based teams)?!"
No, of course not. But let's dive into a real-life example to make the things clearer.
Imagine a complex product, with a serious back-end platform, and a thick client application.
To make the things even more interesting, assume the client and the back-end using different dev platforms and operating systems (MS Windows, Android, iOS).
It may simply be just not feasible to have a single team working on such a plethora of technologies. A team of such kind will, most probably, end up being mediocre in everything it does - instead of excelling in a narrower set of tools and technologies.
I don't think it would be reasonable to expect each and every universalist developer in a team to master mobile, embedded and back-end applications equally well.
And this means that there ought to be several "tiers" (I deliberately don't call them "layers") into which development efforts will be grouped.

Diversify story sizes, or else...

Disclaimer: all the statistics below are deliberately not exact, but rather based on the gut feelings (for multiple reasons). 

We seem to have come to an interesting situation: the distribution of our stories' sizes is very lopsided.

After breaking down all the "epics", we appear to end up with:

• Almost no 1 Story Points;
• Very few 2 and 3 SPs;
• Even fewer 5 SPs;
• The majority of stories being 8 SPs;
• Quite a significant number of 13 SPs (and that's the highest estimated effort before getting into the "epics" area).

So, bottom line: most of the stories in our backlogs (probably, 70-80%) seem to be 8-13 SPs, with the remainder being primarily 3 SP-ers.
And - just to eliminate this topic from the discussion - no, this phenomenon doesn't seem to be a product of so-called "story point inflation". 8 and 13 SP-ers are really that.

In my opinion, this is quite an unhealthy situation, with a multitude of drawbacks:

What do you do if there is some spare time left in the Sprint?

Occasionally, a team may find itself having finished all the stories it had committed to in the current Sprint - and still with some free cycles to burn before the Sprint ends.
Yes, I know, with the stories being fine-grained enough, and the team members being good with the estimations and planning (let's not forget the execution too!), this situation wouldn't be too common... But still, this may happen.
The stars aligned, the integration went miraculously smoothly, the architect had an epiphany with an elegant and easy to implement pattern... Doesn't matter. The bottom line is that the team suddenly ends up having some 2-3 spare person-days in the Sprint.

Initially, my concern was that - in theory - according to the "dogmatic Scrum" (yes, I'm aware that this is an oxymoron :-)), the Sprint content is supposed to be locked once the planning stage is finished, and the team has committed to deliver the certain set of stories.

But then (thanks to Chuck van der Linden's comment) the understanding "hit home": this should only refer to *external* attempts to modify the Sprint content for the team; it is perfectly fine for the team itself to pull more stories into its iteration!

So, how would (or should?) the team utilize this capacity?