I have a similar experience. It took me awhile to understand the main "working area" of math was the manipulation of abstract properties, not the examples of the properties themselves. If you learn math by rote, you learn to identify certain procedures to apply to certain problems of properties, which is effectively manipulating properties following a way that is already known. But you will have near zero transfer. But understanding math is about understanding what properties hold, and what happens under different operations. At a high level, math problems revolve around isolating certain abstract properties initial and derivable relevant to your question. While coding is the opposite, the main "working area" of programming is applying operations to examples. The properties themselves are usually quite basic, although seldom rigorously defined. In more advanced levels you start using math more (intuitively or rigorously), such as isolating invariants in loops.
I've also thought that math syntax is very poorly structured and places enormous cognitive load on the user. In code, you have both formal and technological methods to make reading it more efficient. Languages are rigorously defined by CFGs to produce (largely) unambiguous syntax, while LSPs and other parsers take off a load of the cognitive load in parsing, identifying and recognition. For math it is the opposite. Take how in calculus d looks like a variable but is actually an operator, the concept of which they have never learnt before. One of the elementary things calculus learners struggle with is unlearning the syntax rules they have acquired thus far and trying to unconsciously conceptualise what an operator is. That ambiguity places an unnecessary cognitive load on them.
I wonder if in the future this will change. Looking at the history of mathematics, formulas used to be described in plain language, which likewise placed excess cognitive load because of its ambiguity and unnecessary information. Take the solution to a quadratic from Al-Jabr:
"What must be the square which, when increased by ten of its own roots, amounts to 39? The solution is this: You halve the number of roots, which in the present instance yields five. This you multiply by itself; the product is 25. Add this to 39; the sum is 64. Now take the root of this which is eight, and subtract from it half the number of the roots, which is five; the remainder is three. This is the root of the square which you sought for."
Which is really just x^2 + 10x = 39. It may be beneficial to conceive of some other way to structure the language of math so it can be a more powerful cognitive tool.