First of all, let's acknowledge that many (the great majority of?) programmers have little or no use for math, and know it, and are correct. That's totally fine. I think danso's comment captures this well, with references to UI design, domain knowledge, engineering practices, etc, and dxbydt similarly mentions "git rebase and jira tickets". So let's assume we're restricting ourselves to programmers who do have a use for math (and hopefully know it).
FIRST PROBLEM
TFA's introductory claim is apparently that there are programmers who say "math is useful, I want to use it, I don't want to read or write proofs", and that this is ludicrous. It's absolutely not ludicrous.
Yes, a working mathematician's job is to explore and understand the space of mathematics, and yes, that is inextricably bound up in proof. And I would suggest that learning more about math proof is a soul-enriching use of anyone's time (in the same broad vein as learning Latin). But techniques of calculation are one of the valuable outputs of mathematicians, and it is reasonable and effective for a person with a task to say "I would like to have more powerful techniques of calculation, and I don't want to learn proofs".
For example. Certainly it is possible to learn how to do Gaussian elimination, and use it to solve systems of linear equations, to good effect, without being able to prove that elementary row operations preserve the system. Maybe it helps? Maybe it doesn't? If you want to invent a new technique, I imagine that in that case being able to prove the correctness of the existing technique probably helps a great deal. But what's unreasonable about the person who says "I have these equations, I need to find the values (if any) of these variables here that make all the equations true, and I'm too busy to learn any proofs today (and too busy to write any proofs ever)"?
For a simpler example, we used arithmetic just fine before ZFC.
SECOND PROBLEM
Maybe this is actually two problems, intertwined. And maybe both of these problems are quibbling.
Primus, he says "Mathematics is cousin to programming in terms of the learning curve, obscure culture, and the amount of time one spends confused". I think this is highly questionable. Mathematics is far harder and more baroque than programming, not least because as a discipline it's nearly one hundred times older.
Secundus, after acknowledging the insanely annoying tendency of math papers to make up their own notation without ever defining it, he claims that the non-mathematician's confusion is comparable to the non-programmer's confusion at for(;;);. No, it's not comparable. The math case is hard because someone failed to tell you what you need to know, and no one wrote it down anywhere. The for-loop is only hard if you did the opposite: failed to read what was actually written down (e.g. in K&R) and took someone's word for it that the standard and general form of the for-loop is for(int i=0;i<LIMIT;i++){ /do stuff with i/ }
My claim here is that the learning math - even just the calculation techniques - is genuinely inherently hard. Partly that's because it's so overwhelmingly useful that if it wasn't, we'd already know it; clever students know more calculation technique by age 15 than most professional programmers know about programming. But on the other hand it's also contingently hard, because mathematicians aren't generally very interested (nor incented) to export their product so that outsiders can make use of it. Which I guess isn't so terrible; once someone else labours mightily to learn all that very-hard math, you can hire her at an exorbitant rate to make use of the calculating techniques she has learned. Or if you want to get that benefit without paying the exorbitant rates to outsource the math, you can roll up your own sleeves. Good luck!