Longer sprints are the path to the dark side
A sprint change every two weeks is exhausting. Sprint Review, Sprint Retro and then Sprint Planning. This all costs a lot of time and nerves. If the sprints were three or four weeks long, these "sprint change meetings" would take a lot less time.
This or something similar usually begins a dangerous change of an established Scrum process without illuminating the counterarguments. The assumption that you save time sounds plausible at first, but on closer inspection, the time savings are not so high, because the Sprint Review and Sprint Planning alone take much longer if the sprint duration increases.
Here are some more arguments in favor of a shorter sprint:
Significantly fewer user stories from the backlog have to be "ready" and their discussion in Sprint Planning is faster.
It is much easier for a Scrum Team to estimate the work for one or two weeks than, for example, for 3 or 4 weeks.
The comfort zone for the product owner becomes tempting during longer sprints: The user stories can become "fatter" and – supposedly – no longer have to be broken down.
The comfort zone for the team becomes tempting to not “stick” vehemently enough to a user story during longer sprints.
The desire to intervene in the team from the outside and to have things done at short notice on the side becomes more likely during longer sprints.
There are fewer options for longer sprints due to the rarer sprint retrospectives to perform the "inspect and adapt" step.
=> "Less room for the team to improve"
Likewise, in longer sprints, there are fewer opportunities for the product owner to perform the "inspect and adapt" step due to the rarer sprint reviews.
=> "Less room for the product owner to improve the product"