The last big code review I did optimized for developer time and lost so poorly on execution time and memory that it ended up killing them later.

IMO this illustrates a problem I've long felt existed in the "optimise for maint/development time" school of thinking. I call the problem "death of a thousand cuts". Each decision in writing a program when answered with "do whatever is easiest to code" adds a tiny of bit of fat to the code. Once the app is complete the code becomes like a nice steak, marbled with fat. And just as its nearly impossible to remove the fat without turning the steak into something rather different (groundbeef) its nearly impossible to remove the fat from such a program without a pretty much complete rewrite.

I really think that the "optimise for maint/development time" needs to always be tempered by "so long as unnecessarily wasteful constructs are avoided" and "as long as the dev/run time benefits are aligned". It is possible to write reasonably maintainable code that is also lean and efficient. It just takes a little care and knowledge. The problem is that a lot of this knowledge is what most people (even me) would call premature optimisation when looked at in isolation.