I don't think you and the parent post are talking about the same kind of speedups. Of course choosing the right algorithm and data structure is your job. How you tackle the problem is definitely your job, not the compiler's.

But in general, unrolling loops, caching (some) results, and eliding redundant code rightfully is the compiler's job. That's a different kind of speedup.

Picking the right data structure and algorithms gets your code in the right algorithmic complexity range - did you implement a naive linear algorithm, or did you figure out a way to make it logarithmic? Or maybe even average-case constant? Compilers are generally not good at making optimizations that change complexity class. (Possible, yes, but not commonly.)

That's not what jordigh is talking about. Let's say you figured out a clever way to get your problem to O(log n). That's definitely your job. But in practice, constants matter - that is, 10 log n is way, way worse in practice than 2 log n, even though they are both O(log n). And that's the kind of optimization that compilers may be better at than you. Once you have convinced yourself that the performance of some component matters, a good principle is to figure out the best complexity class you can (using the "right" data structures and algorithms), then write the most idiomatic code possible.

Regardless of whether or not your main point is true in general, most scientists don't know and will never have time to learn data structures and algorithms. So, for this domain at least (scientific computing), the compiler is getting the job anyway.