Sprints provide natural alignment for multiple teams trying to coordinate. They also provide data about how your team makes software, frequent (scheduled) points when change is acceptable, and repetition that allows habits to form. And for teams that struggle with it, they provide a great excuse to push back on a requirements team that refuses to provide details and struggles to break down requirements into chunks that can be addressed in the duration of a single sprint.

That said, they aren’t magical. They are often misused. Not every team and every project needs them or is faced with any of the problems sprints set out to solve. And there are lots of ways to build good software.