I understand that Concerning might seem to fall in the valley between useless and incorrectly placed.
Let me go off on a tangent and make my case for it: it’s a good temporary, low-overhead tool for chunking of concerns. It’s “good enough for now” instead of “perfect or nothing”.
It allows me to group methods together while I’m in context and express “this all goes with the same chunk” without needing to break out into another file, typing three boilerplate lines of code. It’s communicative.
In the same spirit as the H1-H2- model, I can just markup my H2 here and there and keep writing instead of needing to declare-extend-include. If I reorganize later and learn new things about the future, it’s easily undone without worrying I’ll break something. The code works exactly the same, but what it communicates to humans changes.
I don’t think long term you’d want a component with a bunch of concernings laying around. But taking that first step of chunking while you have the context in mind and the future complexity is unknown is super useful. I can come back another day, when my concern has grown large, and take the time to place it into its own file. Or I could have learned that this didn’t complexify as expected, and remove the concerning boundary. It’s a lean, iterative tool to me.
If I may make a gardening metaphor (I’m propagating pothos’ these days):
Concerning is the water jar I put my cuttings in to grow roots. Maybe it will, then I’ll transfer it to its own pot – or maybe it won’t and a pot wasn’t necessary – in which case I saved the effort.