It's less about what you like or dislike and more about aligning a collection of practices you've seen work well to the situation and constraints, which is why variety of experience helps
I'm not sure why stirring up shit or inflaming egos would necessarily happen with such conversations. Skilled engineers often start a solution proposal by explicitly outlining what they are optimising for, known limitations etc which all help create a baseline to describe "taste"
The language matters a lot here too:
> For instance, map and filter typically involve pure functions, which are easier to reason about, and they avoid an entire class of off-by-one iterator bugs.
That's not how "for loops" work in many programming languages! Python being the most obvious, and by some measures the largest programming language of all.
If they are principles, the discussion around whether to apply them can at least be fruitful. "Taste" is bound to devolve into "I like this" vs "I like that".
I don't buy into the "everything has its upsides and its downsides" advice given in the article for the same reason. It's a useless truism. It's a taste:-
I have 1 new feature ticket in my backlog, 3 support tickets, 2 failing tests, and 2 performance regressions. "Premature optimisation is the root of all evil" informs me about the feature work, as does "Make it work, make it right, make it fast". "Reproduce locally" will be my north star for the support, the test failures, and the performance work. Add "Find and measure the bottleneck(s)" for the performance work, as well as "make sure the new code is actually faster than the old code" before checking it in.
I don't need to invoke the maturity of any particular coder for any of this.
Another problem with letting "taste" into the discussion is that you can cheapen principles: you think this code needs tests? "Well, there are upsides and downsides with that", "You're just being inflexible, which is immature". Neither tasteful reply will help you answer whether the code needs tests, and it stirs up shit in the team because it makes it about people, not work, so egos will get inflamed.
>> Personally, I feel like code that uses map and filter looks nicer than using a for loop
I'm not going to argue the person, I'm going to argue the principle. I use map and filter in my business logic because I can do so without mutability. My business logic should reflect the requirements and customer expectations - deterministically. The principle of making the source code pretty is a distant second to the principle of making the code deterministic. If the requirements change from "apply the correct tax rules" to "apply the correct tax rules, if the system is in the right state", then I might well bring in a bunch of mutations to make that happen.
>> is more straightforward to extend to other iteration strategies (like taking two items at a time).
Nope, items.pairs.map((x,y) => ..). Didn't need to discuss maturity.