There are many common tradeoffs in programming.

I would actually reword yours from "functionality versus simplicity", since they are not a continuum.

Time vs Space is probably the most common continuum. You can spend time computing values, you can pre-compute and cache values. Sometimes you can store partial values and then do partial computing.

Parallel versus Serial is a common continuum. Many tasks can be broken down and spread out, but gain overhead of managing the work. Graphics cards tend to take this one to an extreme, with an enormous number of parallel processors on a graphics card, each able to do a tiny amount of serial work.

Different approaches have tradeoffs, procedural, functional, declarative, and other models can all be used, each with their own sets of benefits and drawbacks.

If I were to judge a programmer by the code they write, I would look primarily at the ease of understanding the code. In rare situations where it is difficult to immediately understand, I would expect a comment at the top explaining it. Most of the code should be laid out in an easy to understand format, with good naming conventions and following good practices for whatever language and tool is being used. If a segment could not be made simple, I would expect a descriptive comment "Sorry for the ugly code, the original was too slow. I'm using the algorithm described in the siggraph 2012 paper called ___ by soandso, a pdf of the algorithm should be in the same directory" so I can still understand what is going on even if I would struggle with a tiny block.

As part of that understandable code, I would expect some occasional comments about size/space tradeoffs if they were important in the code.