What's so bad about four-week sprints?

I've worked in various software teams that use scrum for the past ten years. Some of these teams use two-week sprints and some use four-week sprints. Most software teams I've talked to implicitly believe that shorter sprints are a sign of health and scrum "maturity." Four-week-long sprints are for software teams that are still "children" at practicing scrum. The dominant belief is that those teams should get better one day and move to two-week sprints.

My personal experience, though, is that teams with two-week sprints carry over more work, experience higher deadline pressure from management, and, worst of all, spend a higher ratio of their time in sprint ceremonies rather than implementing and deploying code. Two-week sprints involve three long meetings (sprint demo, sprint retro, and sprint planning) every other week, which is twice as much time spent in meetings as those who only have those meetings every four weeks.

Finally, I have observed that the ability to deliver sprint commitments more directly depends on how much of a team's work is dependent on other teams as opposed to being independently deliverable. The larger driver of the ability for work to be "independently deliverable" is the overall organization of the engineering department. Teams that can complete their work independently are just inherently able to deliver smaller batches of work more often, and it has nothing to do with their scrum "maturity." So my takeaway is that engineering departments who have teams experiencing "trouble" with two-week sprints should probably re-org their teams, rather than flog the "you aren't agile enough" horse.

So, what do you think about sprint length?

What's so bad about four-week sprints?