Firstly this trait is not at all exclusive to smart engineers - everyone falls into this trap at some point.
I think one thing that's helped teams I've lead/helped lead in the past, and helps with a huge host of team working issues too, is by setting norms, and documenting them.
For example, in your team's "norms and values" or "way of working" doc, you could include simple things like coding style (in JS land most people just say "use AirBNB style" here).
But it can absolutely also have things like "don't add unnecessary complexity".
Reading your post, I think you can even quantify it too. You mention being able to count the number of bytes or microwatts any given approach will save or cost, that it's objectively measurable? This is great - you could decide (as a team, or let the team lead or whoever else decide) what the approximate limits should be. Complexity itself can also be measured (e.g. cyclomatic complexity). So you could actually be "real engineers" and decide what the trade offs are for your team, or for your target hardware.
All of that aside, it's also good to try and keep an open mind to other peoples' solutions and communicate with each other when deciding what the best approach is. Open, transparent and prompt communication is worth so much, so make sure your team keeps working on that too. (I've worked with some embedded teams that were distributed and almost never spoke to each other. It made things... interesting!)
I think one thing that's helped teams I've lead/helped lead in the past, and helps with a huge host of team working issues too, is by setting norms, and documenting them.
For example, in your team's "norms and values" or "way of working" doc, you could include simple things like coding style (in JS land most people just say "use AirBNB style" here).
But it can absolutely also have things like "don't add unnecessary complexity".
Reading your post, I think you can even quantify it too. You mention being able to count the number of bytes or microwatts any given approach will save or cost, that it's objectively measurable? This is great - you could decide (as a team, or let the team lead or whoever else decide) what the approximate limits should be. Complexity itself can also be measured (e.g. cyclomatic complexity). So you could actually be "real engineers" and decide what the trade offs are for your team, or for your target hardware.
All of that aside, it's also good to try and keep an open mind to other peoples' solutions and communicate with each other when deciding what the best approach is. Open, transparent and prompt communication is worth so much, so make sure your team keeps working on that too. (I've worked with some embedded teams that were distributed and almost never spoke to each other. It made things... interesting!)