I recently had a good internal discussion on 2 week versus 3 week sprints getting ready to kick off a new project for a client.
This is a debate that's been happening in the agile community for well over a decade, and while there is now broad consensus 10 years later that 4 weeks is almost always highly undesirable, the thing to remember is that the quality, caliber and discipline of the team is absolutely essential regardless of sprint duration.
I Just Want to Dance!
The most common argument against two week sprints is that the planning ceremonies occupy too much time and effectively reduce the team's delivery time from 10 days to less than 8. This is true for severely under-performing teams. High performing teams should be able to land demo and retro in one day and planning in as little as half a day. If the only time a team communicates is during these ceremonies, the time will drag on even further.
Performing teams communicate and practice dress rehearsals of demos, have a backlog groomed and ready to go and in some cases, might even have stories already decomposed and ready to go (signaling strong alignment with business prioritization).
Deployment Happens
The other common argument is that deployment time cuts further into delivery time, and now that 8 days is more like 7 days because it takes a day to deploy. This is true of teams that are practitioners of cargo cult agile development. If you don't have unit tests and automated builds in place, you _will_ feel pain each and every sprint.
Snake Oil
One solution to this dilemma that sometimes comes up is to start with say 3 week sprints and then, when the team has "earned" 2 week sprints, reduce the sprint time accordingly. This is an anti-pattern for the simple reason that you can't improve what you can't measure and if you go around changing sprint duration, velocity becomes corrupt. This means that your ability to predict future velocity is severely impeded which affects budget, staffing and obviously has schedule implications.
Why Two Week Sprints Work
Two week sprints are highly advantageous when you have a high degree of risk and delivering new innovation because they provide tighter intervals with which to adapt and adjust. While 3 week sprints can be successful, most often they are merely masking the lack of efficiency of the team and providing a fig leaf to hide behind- in my experience in almost every case, you will find that productive, heads down time turns out to still be just under 2 weeks!
When building a team, you should settle for no less than A-Team players that are going to kick ass and take names from day one. If you do the heavily lifting to invest in building the right team, the sprint duration won't matter nearly as much, but if you are not committed to this from day zero, no amount of sprint duration optimization will save you from failure.