In the same way that writing and performing a new song is "just memorizing prior patterns and law"

or that writing a new book is the same.

I.e. it's not about that. Like sure it helps to have a base set of shared language, knowledge, and symbols, but math is so much more than just that.

Programming competition problems are also much more than just memorizing patterns, that was the point of his post.

I think you've missed a big part of maths - yes knowing those things is necessary. But then you also need to be able to see how a difficult or complex problem could be restated or broken down in a different way which lets you use those techniques. Sometimes this is something as trivial as using the right notation or coordinates, sometimes it's much more involved.

In math, you usually need to prove said simplifications. So just memorizing is not enough. As you get more advanced, you then start swapping out axioms.

In programming the simplifications has to be correct even if you don't prove them, and being correct isn't that easy.

Pedantic: how do you know something is correct without proving it? How do you know you have covered all possible edge cases? /Pedantic

In all seriousness, the intersection between correctness and project delivery is where engineering sits. Solutions must be good enough, correct enough, and cheap enough to fit the use case, but ideally no more than that.