Timothy Lochner

Except in few select cases, such as two engineers deciding company coding standards.

It absolutely does matter to anybody who does live ops. Holding on to comfortable patterns that create bugs hurts the live product.

Same for game client code. Also when you get bugs caused by others (even eg mem corruption). Also changing or shared responsibilities

I get your point. A lot of time is wasted on holy wars that don't mean anything. Except emacs vs vi, where the vi people are just wrong.

But the "this takes time away from development" argument always chafes, because frequently it's employed as a hollow argument (1/2)

As in "what I waste time on is important, but what you waste time on takes away from development time on my priorities".

I would say that focus on what you can change. If you see something cause bugs often, bring it up. If it gets overruled by a superior, then

Either accept it or find work elsewhere. Life's too short.