Yes, you need to push back on those people. They're the type that get high on code golf and end up writing unmaintainable one-liners measured in kilobytes for fun.

Even though I like intermediate variables myself, I've been told the same thing when co-authoring code.

What these anecdotes suggest is that this is subjective, and I think it can be overdone. I don't think objective general rules can be established from the article, even though I think it's good advice.

In my examples, I was overdoing it and causing too many indirections, creating leaky abstractions (leaky because, in my context, the abstraction was not tightly self-contained and understanding the "implementation" of the abstraction was necessary to understand what the line of code that was using it was doing).

I don't think it's a black-and-white matter. Your reviewer might not necessarily have been a moron, or might have lacked the self-awareness to realize they were imposing their own preferences onto you. But there's a slight chance that you legitimately confused them with your indirections. Hard to say without context.

I guess this is go, and I don't know what the scoping is. In C++ I also suggest putting as much in the if as possible, because it limits the scope of the variables.

I review a ton of code and have a bunch reviewed in turn. I don't remember that last time I've had this come up. Either direction really. I guess I'm lucky. We just split naturally in similar places.

Well it actually depends.

Does it make the code more readable? Like you have several if statements using the same things (and/or else if)? Yeah then it's probably good.

If you have an if (work.lengt() == 0 && stacked_work.length() == 0) and that's it, probably not. Depending of whats happining then of course.

Be creative guys! But also dont be too creative :-) Think about the poor coder doing something with all that in a year or two, let's make his life less miserable (It's probably you, too).