directory-per-device is a best way to manage robot config _if you want to stick to git_.
If you combine "directory per device" with "git forge, like github or gitlab" then most of your concerns disappear completely:
- "They’ve never used a terminal, let alone Git." - Solved! Github and Gitlab have online file editing, so no one needs to worry about terminal at all. It's just a slightly weird web editor. They can even open PRs, so you can have linters etc.. checking the changes before allowing them in.
- "has to learn branching, pull requests, merge conflicts" - Almost solved! Github/gitlab deals with this for you.. and with 1 dir per robot, there is no merge conflict unless you have multiple people editing same file for same robot.
- "You end up with two bad options: Train everyone on Git [...] / Route every config change through your engineering team" - or option 3, teach _few_ people in the ops how to use git web UI, and ask them for help.
- "Running a fleet in production means you often need to answer questions like: Which robots have vla_model_3 enabled?" - "git grep vla_model_3=on", that takes <1 second for all cases under 1K robots. Or build dashboards updated on "push" trigger. This will also let you answer more advanced questions, like "Which robots have vla_model_3 enabled _and_ reported VLA errors in last 1 month"
- "You can't find every file where feature_x: true without opening and parsing every file in the tree" - true, but what you've omitted is that once tree is cloned, "opening and parsing every file in the tree" takes less than a second (if you have under 1K robots). And of course, if you are serious about maintenance, you already have a database full of logs, events, telemetry... So adding config there is just one more step.
In a lot of cases, Git works pretty well. Yes, you might need to design and document schema, maybe write some scripts to enforce it, but that's what the whole "software design" thing is about. Maybe add few dashboards, too - but you'll likely already have this set up for telemetry, so this is not as big change as may appear.
A biggest reason to walk away from git is the permission issues, you are not going to fix that one. And when you get to 1000 robots (not 10!) your git gets kinda slow. Or if you are misusing config system and updating it all the time, instead of only during initial commissioning and troubleshooting events.