>Calling the algorithm design "foundational" is like saying it's foundational to understand how an intake manifold is designed in order to build a car.
Here's a big picture view, the most talented developers I know have a very good mental model of low level details, and also tend to be pretty good at algorithmic questions. I don't think that's a coincidence.
I know that day-to-day programming tends to consist of solving rudimentary problems and worrying more about high-level code organization and architecture rather than micro-optimizations of some function. But it has also been my experience, that even in those cases there will be times when you will run into a problem that will require you to put together an algorithmic solution with a data structure you learned way back in uni that is analogous to the kinds of puzzles you disparage.
As a challenge, why don't you try to do one of those puzzles per day for a month - I guarantee you will find value there.
I take a different view. It's an attitude that recognizes tradeoffs.
In an ideal world with infinite time and no responsibilities, we should learn all of those CS theories in addition to our programming skills.
But we don't live in an ideal world. And there is only so much time to devote to learning.
Hence, one must choose and prioritize which part of the field to excel at.
I know it's easy and fun to use frameworks that abstract all the gory low-level details (the equivalent of calling a built-in sort function on a list of numbers), but somebody has to write those frameworks at some point. Don't get me wrong, I'm certainly impressed with the work that the Orleans team did and it would be great to read a write-up on the design of this framework. I suspect a write up on your 'distributed collaboration system with event sourced data in Microsoft Orleans' would be less interesting because the best part would read 'and here I used Orleans to do all the hard parts'.