My thought is that component teams are generally a dysfunction. Larman/Vodde cover the pitfalls of component teams very well in this book: http://www.amazon.com/Scaling-Lean-...0321480961
I think Cohn covers them well in his book too, though I wish he would go further in pushing for Feature teams.
One of my problems with SAFe is that it condones component teams too much in its graphics and elsewhere. IF you have fairly permanent component teams, then it's going to be hard to Agile, since it makes it hard to deliver end to end features every couple/few weeks.
Some other comments:
> The issue is that in order to deliver features, each team must own the entire codebase,
I'm not sure that this is true. In any product, the entire product group (all Scrum teams working on that product) collectively own the entire code base, and collectively share the same Definition of Done.
> idea of having component teams fulfill a Product Ownership role
This gets ugly quickly and has one major, fatal flaw. For any given product, there is only one Product Owner or one "Chief Product Owner" if you prefer that term. That person has final say on the order of the single product backlog, including any "component team's" backlog items. The entire product group shares the same product backlog, and the same Chief PO. Now, if you wanted a team level PO for the component team, that might be ok, so long as that person answers to the Chief PO on ordering of the backlog.
Another fatal flaw of this approach is that the Product Owner is one person, not a team. This is a very strict rule in the Scrum Guide. My preference, if you must go down this road, is that the consuming teams be treated as important stakeholders, and help negotiate with the producer team to define interfaces to the components. But alas, remember, for a component team, the PO gets to control the "what" (likely this is interfaces -- inputs, outputs, exceptions, etc), and component team gets to control the "how" (how everything works below the interface level).
My strong preference is to use only feature teams, move teams towards feature teams, and teach feature teams how to co-operate to achieve shared goals. Larman has some good stuff on all of this in the book above and in this one: http://www.amazon.com/Practices-Sca...gy_b_img_y
I should mention that Larman's books are not for Scrum newbies, but scaling Scrum is not for newbies either.