If not, why not?
I’ve worked in companies where sprints worked fine and others where they became a source of frustration (largely I think due to overly ambitious sprint planning).
Disclosure - I’m one of the founders of a company making a new issue tracker [0] and how best to support teams that work in sprints/cycles is something we care quite a lot about
0: https://Kitemaker.co
We don't get much value from them because there is little sprint planning, and 2 days before the review there is a push to figure out what is "done" to present.
I have worked on other teams that embraced the planning aspect better and it was a source of reassurance that everyone was on the same page.
The primary value (when I was on a team that did it "right") was the common context that was shared by all and represented in the kanban (literally, sticky notes on the wall and some masking tape). There was transparency and traceability. I'm not sure it made us more "efficiency" or "productive", but i removed a lot of frustration of being in the dark about what the team is doing.
But sprints does not necessarily equals cycles, and cycles does not necessarily equals Scrum or Agile.
I totally agree with you stand that "overly ambitious sprint planning" is the root of all evil, many teams forget that planning is not a construction plan but more of a show of intents and you can see the stress level fluctuating between the start and end of sprints.
Another big problem is task estimation, we know that we are bad at it but the "process" forces us to estimate anyway. This in turn leads to more of the above mentioned stress since we usually under estimate.
I found that many times usually Kanban, or ScrumBan works quite well and mitigate some of the mentioned problems.
It's frustrating due to overambitious programs and management 'metricizing' it.