I think that multiple teams should start at the same date. But do they really have to?
Yes and no. You're trying to parse a poor-quality question, and exam practice questions are (by definition) not questions taken directly from the exams. Furthermore, just because a question is in an exam doesn't mean it's got real-world significance.
If you consider a framework such as Nexus, the overall increment (the "Nexus") kicks off and ends at the same time for all teams. If you think about it, this is a hard requirement for ensuring that cross-team work is integrated at the end of each increment.
On the other hand, Nexus doesn't actually require that team Sprints within the Nexus start or stop at the same time. It is certainly strongly implied, as doing so makes integration between teams much easier, but there's nothing in the framework that stops you from having a two-week iteration for one team, and a four-week iteration for another, or having one team end its Sprints on Wednesdays while another team ends theirs on Fridays. However, the framework's design ensures that Scrum teams can't move onto the next iteration until the Nexus is complete, so there would seem to be little value in having different start and end dates. In fact, allowing team cadences to diverge would break the per-iteration feedback loop that is the cornerstone of both Scrum and Nexus!
Furthermore, while scaled agile is largely about reducing dependencies between work streams, they are being scaled precisely because the work needs to be integrated at the end of each iteration. Truly agile organizations will interpret this to mean frequent (if not truly continuous) integration between streams, while less agile organizations will typically fall back on an explicit integration step at the end.
Running Sprints with different cadences inside a Nexus seems like a process smell, and I can't think of a pragmatic reason for it other than work-product dependencies. Such dependencies are inherently anti-patterns, and suggest that the Nexus Team or the Scrum-of-Scrums isn't managing the top-level Product Backlog correctly.