I think at least 3 parameters (dimensions) we want to take into account. 1) knowledge of how to work in a team + how to organize work, 2) knowledge of developing software (system), and 3) knowledge of the business domain. There is no prescription for the format of retrospective. Any group can adjust it based on their maturity.

When I have a mature team = they know to build SW systems, they know to work in a team, they are experienced with strategies of SW systems, and they have an overview of the business domain, such a team will go directly to strategic issues and will discuss the conceptualization of they work.

When I have a junior team, I can expect no teamwork at all, even deliberate sabotaging of the team. In a situation when maturity is low in any dimension, it is not a problem that retro deals with atomized items. The coach teaches the team to speak and to work as a group together. Here any format of feedback is useful.

In all cases, I haven't found a retro waste of time yet. It was always helpful. Even if it ends up sometimes in disaster and fight, at least it help us to uncover hidden tensions that we can address later in a more appropriate way. Context matter.