Optimizing for the sake of optimizing is wasted money.

If the customer has given you a 300MB budget and the application is able to perform its job with 180 MB, and keep the customer happy, there is no point paying for development costs to bring it down to 50 MB.

There are other projects to move into, instead of burning money with non-existent project delivery acceptance criteria.

The whole premise of this article was to optimize programs for speed, which is also pointless if your program is already fast enough. They also don't take into account programmer time spent to optimize the project, how easy it is to find programmers that work with that particular language and that can deliver performant software, etc.

Your criticism is valid, but I feel like it should be applied to this whole article rather than this particular point. I like how stuff like that is described on the Computer Language Benchmark Game: "… a pretty solid study on the boredom of performance-oriented software engineers grouped by programming language.". You could also probably substitute "boredom" with "ego".

Indeed, it applies to any kind of optimization in general.

Not using memory that's lying empty isn't a win. There's nothing better about "I didn't use a reusable resource that was lying about unused."

The same could apply to CPU usage, which is what this whole article is about.