Scrum sprint length: three, two, or one week(s)?

Suppose you are doing three-week sprints.  Should you consider moving to two weeks?  If you are already doing two, should you move to one?
Some teams want shorter sprints because they need more feedback, a quicker turnaround, and more interaction with the stakeholders.
If you are doing Scrum (or even just being Agile) well, you should be able to get lots of feedback during the sprint, regardless of your iteration length. If you feel that this isn't happening, yet you want to stay at longer intervals, consider setting up an informal demo with the Product Owner (PO) and a key stakeholder or user halfway through. This informal demo is flexible to happen more often, as much as you can benefit from it. Remember, official Scrum has the PO as part of the team all day every day. This is not commonly followed, so you have to intentionally look for ways to get that continuous, high-touch feedback from the PO. 
On the other hand, some teams want shorter sprints in order to improve focus—to truly get done with half the work in half the time.  This is the real benefit of one-week sprints; if successful, you can increase your output in that one week due to the benefits of increased focus.
Consider one-week sprints if you can possibly deliver genuine value in one week—providing the stakeholders with a potentially-releasable product. Otherwise, I'd keep it at two.
Some teams want this benefit of shorter sprints, but are wary of taking the plunge, thinking that the overhead of the Scrum rituals (estimation, sprint planning, daily scrums, and sprint review) is too high to do in one week. 
I fear this is a straw-man, worry-wart argument.  For a one-week sprint for a Scrum-experienced team, I'd hope to do the demo in one hour, the retro in a half-hour, then do estimation (which works best before sprint planning) and sprint planning in a few hours after that. I would combine these all in one day. The team may need to be involved in backlog grooming/story writing later in the sprint, but this shouldn't be the whole team, just individuals as needed. 
This tighter approach is best done by remembering the goal of sprint planning is to agree on a sprint backlog that the team can begin working on immediately, and nothing more. In my experience, a good morning of sprint planning followed by a team lunch leaves the team extra-productive for the four hours remaining, wherein they get a lot done.
I think there is a different obstacle to shorter sprints that we don’t want to admit to ourselves.  Too often teams feel two weeks is "easier" than one (And three weeks easier than two) not because it is actually easier, but because there is more time that can be wasted (or stolen by unplanned work) without being noticed. That's a "benefit" of a longer sprint you don't want. All the scrum rituals should take half as long in a one-week sprint as in a two-week sprint, so you should have exactly half the time to get done half the work--but hopefully, you will end up able to do a bit more than half the work in a sustainable, fast pace, right?  "It’s not enough time" is a smell that the Sprint length is being abused and therefore wasted. 
In the end, the team should decide 1-, 2-, or 3-week sprints based on how much they can plan with confidence and how much they can benefit from rapid feedback and delivery.