I think the concept of time boxes is more general than in Scrum. While Scrum uses time boxes, the notion that time boxing means that different kind of cadences must be aligned (as in Scrum) is not part of the time box concept. (See the definition of time box on the Agile Alliance page: http://guide.agilealliance.org). For me, a cadence is some form of a time box. And cadence (or takt, as the original Lean term is) is a key element of flow. Anderson has several chapters about that, so I think that is not the discussion.
I am happy with saying that Agile needs cadence instead of saying it needs time boxes. From the discussion, I think that the term time box has become a special meaning that encompasses more than what the definition of time box meant (see above). While that might be an academic discussion, I think it limits the usage of the agile methods. In most environments we use more than one agile method, and we often need to marry the methods, especially in scaled agile environments where different teams use different methods (and still need to work together). I think it helps to recognize the same elements, so that we see where the methods work together (and the work of teams can be joined). So it helps to see that the Sprint is a cadence, it helps to see that the Queue replenishing in Kanban is similar to Sprint Planning. It helps to see that the output cadence in Scrum is decoupled from the Planning Sequence (despite common thinking). If we can see those similarities, we can marry and merge the methods, instead of using one or the other. Using different terms for the same kind of thing leads to fruitless discussions about terms, and not to useful discussion of how the methods can be applied together. That is why I am a fan of things like takt = cadence = timebox. Once we move beyond that, we can discuss if the cadence should be coupled or not (that is an useful discussion).
So, for this discussion, if it helps, let me say: Agile needs cadence. Happy with that?