I think the main problem is that we have at least two use-cases for people using docker compose.
1. the people which just want no special features, but reuse compose configs.
2. the people which want most, if not all compose features, which usually also create their own compose files.
I count myself to the second group. So that's why this kind of "compose - dev - container" works perfectly for me.
What I don't get is what's the plan with the step with the 6.10 feature of the container labels for just icons and webgui url.
I don't know their thoughts and plans, but I would be consequent and just replace the templates with compose-files. They would only need to support the features they want in the GUI and just but unraid specific stuff in labels (as with the comming changes for icon and webgui url).
Even if they would decide to support only one container in the GUI per compose file. It would be a lot more compatible with custom compose files, especially that (at least my impression) a lot of users here use them. It would also allow for people in the second group to to at least basic stuff in the GUI with their custom compose files.
I see the point with the storage location for volumes... but that's something a "power-user" anyway has to deal with. A so called compose based template would just predefine the unraid paths, as the current templates do. But it would be an easy adaption from a compose file that I copy&paste from the internet.
Maybe the labels they implement in 6.10 is only a small step in their plan towards this direction, who knows....