I think it's actually as much to do with having to turn syntax and abstraction into something actionable that describes the solution.
That is, in programming you learn a small set of abstractions (programming language syntax), and the actual coursework in applying that is in how they combine, how to fit them to problems.
In math, you learn a large number of abstractions (notation), that can vary and have new ones across different domains, and which doesn't tell you what it is doing unless you learn all the abstractions.
The latter you can kinda get, if you think about it, but forcing you to actually turn it into something expressed in the former means it is synthesized into something applicable, rather than just abstraction that may or may not be.
That is,
http://upload.wikimedia.org/math/d/f/1/df17b3410e58ac4c285bc...
is harder to understand when you come across it than
total = 0;
for(i = 0; i<=100; i++)
{
total += i;
}
return total;
or
sum([1..100])
You have to convert the first from a symbol that does not describe its action, to an action; the code describes the action. That extra translation step leads to additional cognitive load when learning, at least for me.