"The argument that they magically help you be a better software engineer doesn’t hold water either."

Exactly. Computer Science fundamentals (plus some fields of mathematics) should be on the subconsciousness level of every software engineer worth it's salt. It helps solve problems by NOT reinventing solutions, plus it contributes to get things right first time. Those theories not only lay down patterns (like in GoF Design Patterns sense), but also provide enough rigor to verify solutions are complete.

Lets say, when implementing the game one can unknowingly reimplement buggy version of topological sort. Or Greenspun's tenth rule - "Any sufficiently complicated ... program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." Or consider regular expressions - it's worth to know the expressiveness of the language they can deal with.

And I could even argue, that of course one can do routine work of "coding" "solutions" one after another year after year, but a competitor, who bothered to understand how to overcome routine will outpace you.

The fundamental of SW you've listed are really just useful ceremonials and terms. Of course they are needed, but they are common ground, but without deeper understanding of CS topics there will be a limit on productiveness and problem-solving abilities. Even if those will need to be reinvented.

Maybe I am somehow pervert, but ability to quickly translate problems and solutions to some algebraic structures and back helps not only to write code, but also to notice subtle bugs during code reviews but instantly providing a counterexample.

For example, if concatenation is being implemented (for whatever data, not only strings), I can imaging underlying monoid structure and check axioms. And them point out problems with the implementation (eg, handling identity element incorrectly). And the beauty in it is that the number of "patterns" (eg like in Musser and Stepanov's generic programming) is not that big, so it really helps.