The team owns the code collectively, which means that no developer owns any component. This practice complements moving developers around to different areas of the system and the drawbacks to that practice also apply to this one as well.
What if 2, 3, or more developers each decide that a certain component really should be written in a different way. Who gets to decide how it should be done?
What often happens is that the component ends up with a potpourri of ideas and techniques. It can lack consistency of design which can make the component harder to understand and maintain.
Efficient Software Development Methodology 
I think the point is that in Agile, the teams are self-organized, and own collectively the desgin, code, and all. So the team collectvely will decide which approach works the best.
In theory what you said is correct, but this is just agile hype. In practice what ends up happening is a hodgepodge of ideas and styles where the developers with the loudest voices and strongest connections control what and how things get done. One of the myths of agile is the idea that code written by one developer is just as pristine, easy to understand, and maintainable as code written by any another developer. From my experience – I know this to be patently false.
Another way to think about it is to consider how long would it take you to fix a bug or add a new feature in code that you completed writing yourself a day or two ago .vs. fixing that same bug or adding that same new feature to code written by someone else. With code that you just wrote, you are quite familiar with the ideas, design, data structures, etc. of that code. For someone else’s code, you have to go through it and figure out both what and why it is doing as well as how that code does it. If the code is anywhere close to being complex, then you might have to step through it with the debugger to really figure out what it is doing. This is especially true if you are not familiar with the libraries or frameworks it is using. Because you are familiar with your own code, it gives you a tremendous advantage when working on that code compared to anyone else. You will probably be able to accomplish in hours what someone else might take days or even weeks to accomplish that same task simply because you understand how that code works and are quite familiar with all of the underlying aspects of that code. Also, in general the chances of new changes to that code being correct is greater if the original developer makes them. In complex code, a new developer working on that code is more likely to introduce subtle bugs simply because he is new and not familiar with that code.
If you are the project manager and have been asked by the CTO or a VP to run the project as efficiently as possible to achieve the highest amount of reliable functionality in the shortest period of time – how are you going to do it? Are you going to assign some tasks to some developers and then have other developers go into that code later to add new features? If so, then you will be significantly increasing the risks to the project and increase the chances that it will be canceled due to cost overruns, delivered late, has missing critical features, and making it more difficult to maintain.
By breaking up the system into components and assigning one primary developer to a component, the project stands a better chance of being successful. Assigning a backup developer who spends about 5% of his time reviewing that code provides some backup if a developer should leave the project or the primary developer goes on vacation and a bug needs to be fixed or a minor new feature needs to be incorporated. One way for the backup developer to familiarize himself with the primary developer’s component is to have him write the documentation for it. In that documentation, it should list the functionality, design, classes, major data structures used, algorithms, etc.