As far as I can tell, he means "Why is complex software hard to change" which is a reasonable, though fairly easy to answer, question.
Software doesn't rot. New features or refactors screw it up. New needs or technologies may make it obsolete. But it doesn't rot, and people who talk that way are often busy-body rewriters who want to pitch the existing implementations, with all their Chesterton Fences[1], and begin anew.
Another example is software which interfaces with hardware: Swapping one specific piece of hardware out for "the same" hardware made by a different manufacturer can cause rot, because "the same" hardware isn't necessarily the same in every respect. If your software tickles it the right way, it can expose differences which can cause your software to fail in new and exciting ways. Nothing changed, yet everything's different.
As you expand the universe of things your code has to interact with, this kind of change becomes inevitable. As always, the more points of attachment, the more potential for future pain.
I spend a lot of time thinking about this (http://akkartik.name/about), but lately I try to steer clear of metaphors, because they're so often clear in my mind but utterly opaque to someone else's. So, I don't care what we call it, as long as more people try to fix the problem.
On the face it, that's true. But the reality is that the environment that software runs in is constantly evolving and software that doesn't also change slowly starts working worse until it stops working entirely. We have plenty of software at my work that hasn't changed fundamentally in 10 years and can no longer be used.
Lots of really old software requires equally unchanged old environments and old hardware and that hardware slowly rots too.
Software literally does not change. Except for the occasional cosmic ray, I can think of few things less appropriate to apply the term "rot" to.