Ich würde es in der Gruppe diskutieren und nicht durch PO /SM bestimmen lassen. Das Team sollte hier mitreden. Sie sind die Experten und können sagen, wie oft Lieferungen erfolgen können.
Zum Start würde ich als Dauer 14 Tage empfehlen. Funktioniert ganz gut und steht in vielen Büchern zu Scrum so drin.
Wenn das Team dann gut läuft, kann man die Dauer gerne verkürzen und häufiger liefern.

Außerdem sollte man mit dem Team diskutieren, welcher Tag sich als Sprint Beginn eignet. In der heutigen Zeit ist ja auch HomeOffice ein Thema. Eventuell sind auch andere Agile Teams im Unternehmen die in Sprints arbeiten zu beachten.
Ich habe gute Erfahrungen gemacht, den Sprint Beginn, das Review und die Retro alles an einem Tag zu machen. Dann sollten auch alle aus dem Team persönlich anwesend sein.

Ich kenne es auch so dass der PO das zu Beginn festlegt. Oft noch im Zuge des Setups wenn die Berater noch da sind. Dann einigt man sich auf Sprints zwischen 1 und 4 Wochen und das ist dann erst einmal fix. Klar kann man nach einer Weile z. B. diskutieren ob man generell von 2 auf 3 Wochen geht. Aber der Rhythmus sollte schon immer gleich sein.
Bei uns sind auch die Termine schon weit in die Zukunft geplant weil wir immer an den gleichen Tage Sprint Planung und Sprint Review usw. haben.

Der Scrum Guide sagt dazu nur wenig (wahrscheinlich weil es gar nicht so einfach ist ;).

Für die Auswahl der passenden Sprint Länge gibt es ein viele Kriterien die Einfluß nehmen. Hier ein paar Beispiele.
1. Wie lange kann der PO im Voraus sicherstellen, dass die Anforderungen stabil sind?
2. Wie schnell kann ein "potential shipable Increment" erstellt werden (z.B. bei Hardware kann dass durchaus dauern)?
3. Wie erfahren ist das Team (kürzere Sprintlängen sind einfacher zu planen)
4. Wie oft sind die Stakeholder verfügbar (Z.B PO und Stakeholder nur alle zwei Wochen verfügbar)?
5. Kann das Entwickler Team eigene Erfahrungen beitragen (siehe 3.)?
6. Müssen mehrere Team synchronisiert werden?
7. ...

Ob und wie das Entwicklungsteam eingebunden wird hängt stark davon ab, was das Team beitragen kann.
Es sollte wenn wenn nützlich informiert werden und die Möglichkeit haben sich zu äußern.
Es ist allerdings wenig förderlich erst zu Fragen und dann etwas anderes zu machen.

Aus meiner Erfahrung ist wichtig die gewählte Sprint Länge dann über einen längeren Zeitraum stabil zu halten. Selbst eine Verkürzung von drei auf zwei Wochen macht mehrere Sprints Probleme mit der Planung. Abgesehen davon, dass es in vielen Unternehmen ein Raumproblem gibt.

Mein erster Kommentar auf Deine Frage bezog sich eher auf den Start mit einem neuen Team.
Bei Dir läuft das Team schon eine Zeit, wenn ich es richtig verstehe?
Ich schließe mich hier den anderen Kommentaren an. Die Sprint Dauer sollte über einen längeren Zeitraum stabil sein. Wenn das Team noch einem Jahr feststellt, dass statt 14 Tagen auch 1 Woche als Sprint Länge möglich ist, dann kann man dies ja mal probieren.
Einfach den Sprint verlängern, wenn Sachen nicht fertig sind, geht m.E. gar nicht.
Ich glaube es wird niemanden der Kopf abgerissen, wenn man mal einen Sprint nicht alle Aufgaben schafft. Dann ehrlich zu sagen, dass man sich z.B. verschätzt hat oder unvorhergesehene Aufgaben dazu kamen, macht die Sache transparenter. Mit dem Verlängern lügt man sich ja eigentlich in die eigene Tasche.

Finde ich sehr gut, dass Eure Teams die an dem Produkt arbeiten die gleiche Sprint Länge haben. Fangen die Sprints der Teams auch alle am gleichen Tag an oder ist dies unterschiedlich?
Das mit dem Weihnachtssprint haben wir auch so gemacht... 4 Wochen war der lang.

Wie kommt ihr damit zu recht, dass die Teams zwar die gleiche Sprint Länge haben aber der Sprint Start unterschiedlich ist?
Habt ihr dann trotzdem z.B. alle 14 Tage einen festen Release Termin an dem alle Teams zusammen liefern?

Da hatte ich Dich missverstanden... Sorry!
Jetzt weiß ich, für was das "Ja" und "Nein" war.