Scrum fans will criticise this article on numerous details. But the big point is that a cadence-based process is not very effective for product development. It is for _some_ things, but not for things like programming.
The reason: the cadence disrupts flow.
There are many consequences of this in real use. Some are:
1. Teams have to stop what they are doing and shift their entire focus for a significant period of time every two weeks.
2. Not everyone actually needs to be involved in the entire process of deciding which features to focus on. In fact, many people do not even want to be involved in that.
3. The cadence makes it difficult to accommodate workflows. For example, BDD is inherently a workflow in which there are some handoffs, there is some "backflow", there is collaboration, and there is parallel work. It is a complex process, and if you force time boxes on it, it breaks the process: what happens is that some people are busy while others are waiting. If you remove the arbitrary sprint time box, then work is not constrained by time boundaries, and no one ever has to wait. And please don't tell me that "I am doing it wrong" - I have seen every permutation, and have a decade of experience with various approaches to BDD.