I think that this is what you are getting wrong: the build system is not the workflow.
The build system is part of your workflows. There’s nothing wrong in providing a diversity of settings suited for different parts of them. Thinking that dune can provide a one size fits-all experience is the biggest error it is making. How you operate on projects is contextual and differs from one organisation to another. Other example: testing on the opam-repository CI is currently broken because it seems there is a lack of nuance about which test you can specify on an dune run test, see here.
As for the “I have never seen any other language eco-system do that” line, then the news at 11:00 is that OCaml tooling is allowed to be creative and better than what other languages do rather to sheeplessly copy what others are doing and is being sold to be the best in town.
I’m not exactly sure what ends up being confusing here. Here an extremely simple plan based on profiles that almost disrupts nothing to the way dune operates now:
dev: default set of warnings and warn-error.releasedefault set of warnings without warn-errors.lintwarn-error with more stringent set of warnings enabled.
The worst that can happen is that people will ship (or keep) dead code. But on the other hand I will no longer have to apologize to people that I entice to try to OCaml when they come back to me telling me that the way this dune system operates is crazy, confusing and annoying.