The aim of Scrum, and other methodologies tagged Agile, is -- near as I can tell -- to emulate a good programmer with a team of mediocre programmers. Not that all developers working on Agile teams are mediocre programmers, only that the business wants to achieve good-programmer results while still being able to leverage the wider talent pool and lower risk and cost offered by hiring mediocre programmers, so it tends to adopt formalized processes designed to work well with them in the hopes that following the process will make them achieve good results. The process is a formalization of the relationship a good programmer has with their client, which is known to produce good results; therefore, the process must also produce good results by definition (and any failure to produce good results can immediately be blamed on lack of adherence to the process).
Unfortunately there ain't no such thing as a free lunch, and when you emulate you necessarily incur overhead, which can be prohibitively large if you're emulating something powerful -- plus, if you have actual good programmers on your team, they will either quit or start emulating mediocre programmers to remain compatible with your mediocre-programmer process. Either way, you lose the benefits of having them.
Unfortunately there ain't no such thing as a free lunch, and when you emulate you necessarily incur overhead, which can be prohibitively large if you're emulating something powerful -- plus, if you have actual good programmers on your team, they will either quit or start emulating mediocre programmers to remain compatible with your mediocre-programmer process. Either way, you lose the benefits of having them.