Re: arguing and why not just avoid it:
During my brief (7 year) sojourn at one place that was not-my-company (Google), you end up with a mix of personalities, and it's very hard to convince people who believe there's a Right Way to do things that there is no Right Way, so you just sort of have to muddle through figuring out how to be productive without irritating people, or as an EM, leaving them thinking you're negligent.
Conversely, theoretically, it's hard to convince people who are slopping through and rushing code to slow down. (in practice, this wasn't a problem at Google, but it's worth mentioning for completeness.)
Case study: 6 person team. 1 EM who ended up doing 20% of the code, 1 me who did 60%, 2 who did 10% each, only do things when directly asked, and they couldn't find an excuse to kick the can down the road due to "ambiguity" that was product/design's fault, and then two who, in all seriousness, never contributed code to this year-long project: 1 who wanted OOP-to-the-max InjectedFoobarManagerFactory, another who definitely didn't want anything like that, but didn't really have an alternate proposal, they just loved explaining endlessly and authoritatively why anything else brought up was bad.
(what did they do if they weren't contributing? the first would write vaguely productive "experiments" for other teams, that obviously wouldn't ship, in the code repo they were used to. took them 18-24 months to make their first code contribution to our actual code repo, the other wandered off to some other random project in the org. EM was new and out 3/4 of the project for new child leave)