As somebody living in "Agile", I hate retrospectives. But: If our retrospective was that we actually go through a checklist of things in the 3rd column from the table, they could become really useful. Just a thought.
It's frustrating to me, because it seems to be underutilized in the industry, but lean software development (as discussed by Mary Poppendieck) has been about exactly this idea for around 20 years. She mapped out the ideas from Lean to software development equivalents and mapped out ideas about what constituted "waste" in this field.
These are exactly the kinds of things that people should've been looking at in retrospectives, but it's become deemphasized and is instead a shortened ritual with no useful effect.
What if I our team has a concern that isn't mentioned in a checklist?
What works is when people share goals and collaborate.
My current employer just lets me do literally whatever we want. A service is basically owned by a developer. And so far my customers absolutely love my work.
Not OP, but on my past two teams and my present team, this part has never happened. It was/is just a box ticking exercise.
I think the purpose of having such a checklist is not to limit the discussion to other concerns, but rather serve as a reminder what all the different things can be a problem and should be discussed.
In my experience, the value from retros is a function of the skill of the facilitator.
Perhaps you could be a force for change on your team, by speaking bluntly about not spending enough time on that third column. Others might be receptive to it!