No doubt about it, mathematical notation can be difficult to read. It's terse, conceptually dense, operators are commonly overloaded, etc., etc.
But that's not why it's hard to read. Math is hard to read, I think, because math is hard:
(1) Some core mathematical concepts are fundamentally difficult. Notions like infinity (and different kinds of infinity!) are entirely foreign to our daily experience.
(2) In addition, mathematics is more abstract than most programming. Tim Gowers, in his lovely little book Mathematics: A Very Short Introduction, writes:
What is the black king in chess? This is a strange question, and the most satis-
factory way to deal with it seems to be to sidestep it slightly. What more can one
do than point to a chessboard and explain the rules of the game, perhaps paying
particular attention to the black king as one does so? What matters about the
black king is not its existence, or its intrinsic nature, but the role that it
plays in the game.
The abstract method in mathematics, as it is sometimes called, is what results
when one takes a similar attitude to mathematical objects.
This sort of abstraction is, I think, abhorred by many programmers. But it's the reason single-letter variable names are common in mathematics. There's no way to describe what a mathematical object
is with a name relating it to some real-world, concrete, familiar thing, as programmers often try to do. You can only describe what it
does by writing down some rules it obeys.*
(3) In math, concepts are inherently more hierarchical than is common in programming. As programmers, we're all familiar with building higher-level things from lower-level pieces. And we try, and often succeed, in building them up in ways that let other people use them without needing to know much of anything about the lower-level pieces. In math, there's a similar accretive process, but because the concepts are so much more abstract, it's often impossible to understand how a high-level concept behaves without understanding how its lower-level constituents behave. Mathematical concepts are conceptually hierarchical, whereas pieces of programs are often structurally hierarchical, but conceptually (nearly) orthogonal.
* — (A controversial aside.) An object-oriented mindset can exacerbate the problem by demanding that we reify concepts into objects that represent what they "are". This is often impossible, hence the inscrutable object names we've all laughed and despaired at.
Phil Karlton's well known witticism comes to mind:
There are only two hard things in computer science: cache invalidation and naming
things.
Naming things is hard because, just like in math, we sometimes lack a familiar semantic reference for the concepts we deal with as programmers.
Conversely, in functional languages, there's less need to think about what something "is", because the natural way of programming is to define relations (functions) on a small number of core data structures. Interestingly, single-letter variable names are also common in some functional languages, like Haskell, because it generally doesn't matter what the data is so long as you know what you can do with it. And that information is embodied in its type, expressed in its type signature, and enforced by the type-checker at compile time.