I specifically said that I was talking about an engineering tradeoff, however - that is, when you have to choose between one or the other. Excluded from that is the possibility of improving both memory and CPU consumption at the same time - that means that you haven't hit the edge of the curve, so to speak.
You wrote it as an "pick memory utilization or CPU utilization", stating memory as being practically free. I just wanted to correct that by saying that its utilization is very expensive for the CPU.
Rather the trade off you're thinking of is "caching vs. realtime computation" rather than just "memory vs. cpu". Outside caching, it's pretty universal that more memory utilization just means poorer performance, both in wallclock time and in CPU utilization.
Of course important to remember that increased memory utilization results in increased CPU utilization. The range of degradation is quite wide: Increased cache misses (which cost a significant number of cycles), access patterns not in line with the prefetcher, and increased TLB misses.
It's for good reason that one of the most potent optimization techniques for hot code is to reduce the memory footprint and memory access.