I think arguing each case individually is a trap to avoid. A method I've used with lots of different groups of people, from groups of 4 year olds up, to dev teams, to groups of CEOs, is at the start of a project get everyone together and mutually come up with a set of ground rules around standards and conduct. So things like - we will use this coding style, we will ensure that every function is documented, we will not pursue premature optimisations as long as we are under x power budget, we will not introduce complexity that will be hard for others to reason about etc.
You will have ideas about what these standards should be and you should feel free to propose some yourself during the process, but the aim is not to impose them on the group but to come up with something cooperatively upon which you get consensus. Then write down what you have agreed, stick it in a prominent place and make sure people stick to it. The process should only take about 10 minutes.
Then whenever one of your engineers comes to you with something that goes against the mutually agreed contract you can just flat out say - no, you agreed we wouldn't do that and move on. If something isn't covered by it then have a discussion.
You will have ideas about what these standards should be and you should feel free to propose some yourself during the process, but the aim is not to impose them on the group but to come up with something cooperatively upon which you get consensus. Then write down what you have agreed, stick it in a prominent place and make sure people stick to it. The process should only take about 10 minutes.
Then whenever one of your engineers comes to you with something that goes against the mutually agreed contract you can just flat out say - no, you agreed we wouldn't do that and move on. If something isn't covered by it then have a discussion.