If you have most of those prerequisites -- everyone agrees on a process, you have a good architecture, and the project staff are highly motivated and get along -- then basically any process will work. If you say that scrum only works when you have those, it does not speak well of scrum. The purpose of real engineering processes are to manage projects where not everyone sees eye to eye, you have a variety of per-worker productivity levels, and you probably have uncertainty about what you need or what is possible.
Well Scrum isn't a silver bullet. any process where all parties are not "on board" will likely fail. But Scrum (and more generally agile) does provide a good way to address the issues you mention.
The customer requirements are broken into "user stories"; a set of unambiguous features the solution must have. These are ranked in priority order by the customer. But they are also evaluated by the developers for degree of difficulty and likely effort. If there are genuinely impossible or really difficult requirements they are called out before any coding starts.
Subsets of the features are delivered in "sprints" lasting 2 to 4 weeks. At the end of each sprint the working code is demonstrated to the customer for feedback. This gives the customer confidence and ensures the team don't go too far off course -"fail fast, fail cheap".
Of course developers have differing levels of skill and experience. In scrum the team's "velocity" (the amount of work they can undertake in a given period) is determined by the skill and experience of the team members and is called out up front. If the customer wants top quality in the shortest possible time then he will have to pay for the A Team!
Team "velocity" should increase over time as members build up skills and experience. In my experience a relatively inexperienced developer who is motivated to learn and take on new challenges is better than a more experienced developer who won't step outside his comfort zone.
And people don't always see eye to eye. But in Scrum the team is responsible for delivery. So in a difference of technical opinion both sides make their pitch to the team and the team decides which one to go with.
If somebody just doesn't get along with the group, or isn't pulling their weight (which will be very obvious in an agile project), then that has to be addressed whatever project approach you are using. In Scrum it's the scrum masters responsibility to deal with issues that are making the team less effective.