I've been working with a team recently where establishing a constant velocity has been very difficult. They are basically dealing with a large backlog of defects from previous iterations where they weren't using an agile process. Until this backlog is cleared it's largely academic how long the sprint is - they still get interrupted with a significant number of urgent defect fix tasks every week. Perhaps going to a weekly sprint, at least until this backlog is effectively cleared would help. That way the defects being worked on in that week would be known, with analysis only being done on new defect reports during the week. The sprint planning for the following week can then re-prioritize the work for the following week. This is an example of where the sprint needs to be short in order to handle rapidly changing priorities. However it also demonstrates the difficulty of trying to apply an agile process when a clear quality baseline has not yet been established.
In other circumstances I favour a longer sprint rather than a short one - at least 3 weeks. It gives the team a chance to establish it rhythm of delivering backlog items without the overheads of sprint planning and retrospectives interrupting.