"Sprints" are a very bad name, giving the impression that the team is always running, which is a bad for morale and quality. In reality, they are just "cycles".

I see them like CPU cycles, but for a team. They are a heartbeat keeping team members in sync. It's all about answering what's my next task when I'm done with the current one. If you I work alone, or in a very small team, with no external stakeholder, then I can answer that "just in time" and don't need cycles.

But if I work in a larger team and/or with external stakeholders, then it's not practical to do this "just in time", gathering everyone to decide what should be the next task, every time a team member completes a task. In that case, we need to batch the planning work. That's what cycles are for.

I agree with the author that too often the process feels unnecessarily bureaucratic, and I really dislike the "sprint" terminology, but I wouldn't throw the baby out with the bathwater. Cycles still have a purpose.