If we're confining ourselves to optimizations that make a very small difference per-operation, then I'd generally agree that the vast majority of the time¹, the CPU time doesn't matter.

On the other hand, the core of your argument is somewhat specious:

Anything you do needs to be measured in that light by the person paying you. Is it worth having my person spend 3 days here and 2 days there squeezing out performance? Or, is it worth just buying another machine and having my person actually spend time advancing my business? Because, there's an additional opportunity cost to squeezing performance cause you're not doing something else that actually makes money.

When you talk about lost opportunity cost, etc., you miss a major piece of the puzzle -- it might take me 3 days to find the best algorithm to use (and get it working), but that effort has zero ongoing cost. In fact, I can use what I learned the next time there's a related problem, and I won't be spending that same 3 days again.

However, adding a new server does have ongoing costs. You have to admin it, secure it, keep its software up to date. You also have to plan to replace it when it breaks or ages.

Choosing when and what to optimize is extremely complicated. I tend to agree with the Two Rules of Optimization (I think these are Knuth's?):

1. Don't
2. (For experts only) Don't yet

So, if I were to rephrase your advice, I might say this: don't worry about optimizing your code until it works, and even then only if there is really a performance problem. I may even add that sometimes adding resources² is a better solution than optimizing code -- but I disagree that it's always a better solution.

Beware false absolutes.

Footnotes:

1. I don't like throwing around numbers like "99%" unless there's actually some data to suggest that number. At least as an estimate.
2. CPU isn't the only limiting factor that people optimize for. There's also memory and disk usage, network bandwidth, and a myriad other things that fall under the "resources" umbrella.