What is probably being referred to is software entropy or software rot. These are terms borrowed from or analogous to things from the physical world, but applied to software.

The idea is borrowed from thermodynamics. When applied to software, it means that as you introduce changes into a system, the system only gains disorder. There are techniques that can be used to limit the amount of disorder, such as refactoring, but over the course of its life, there will be a net increase in the disorder of the system. The amount of disorder is often tied to the ability to continue to maintain the system.

Software rot is similar. As you change any aspect of the system, from the environment that it runs in to the underlying requirements that drove the design and implementation, the state of the system changes in a way that makes it “worse”. It could range from cosmetic differences (an underlying UI library is updated and behavior of the system changes) to functional (changes in CPU architecture influence the run-time characteristics of the system, leading to timing or synchronization bugs). Software rot doesn’t necessarily require changes to the software system, but only in the environment in which the software is deployed.

It could mean that, the more you add functionalities to your software the lesser its design stays clean, elegant, and further extendable – meaning at some point, you have to rewrite / refactor substantial parts of it?

Over time there are many things that could happen to a code base that could cause it to deteriorate.

• Multiple developers, of different skill sets editing the codebase.
• Coding standards not being adhered too.
• Architecture design patterns being used ignored to get quick fixes in

These could all lead to what could be called wear and tear of software.

It is true in the strict sense that the software itself does not wear out. But everything else about the entire process of deploying, configuring, and using software does go through changes that can have the same effect in the impression of the user. You’ve listed some of them already. Others include:

• Configuration: the software that worked well when running as a pristine install may start to behave unexpectedly or even exhibit defects that were not visible at first by the time users have finished tweaking the installation the way they want. Just think of the Windows registry: the richest, most powerful software company in the world is unable to reliably diagnose problems arising from too many or conflicting configuration settings in the registry; standard operating procedure is to tell the customer to reinstall the OS rather than spend more than a minimum time trying to fix it.
• User expectations and habits: using the same program for any length of time habituates the user to the way it works. What was initially new and exciting becomes normal. This can work for the product, as users learn the quirks of operating things that they initially considered confusing, but it can also cause accumulating misgivings that eventually culminate in hatred.
• data load: the longer a program is used, the more data it usually has to deal with. Views, reports and procedures that were acceptably fast in the beginning often degrade in performance the more data they have to deal with, until the run times for typical tasks that were once acceptable become unusably long. Again, technically this simply exposes a defect that already was in the software from the beginning (and proper load testing would have aught it), but the impression on the users is one of “wear”: “It’s soooo slow now!”

Many factors can conspire against a program that is considered acceptable, good, or even great to erode its reputation and ability to perform its function.

• That was then, this is now. I visited a museum in Chicago and saw the control panel in an Apollo space capsule. At the time, it was state of the art, the best available technology. By our standards today it would be considered to have poor human factors, clunky old switches instead of a touch screen. Its computer was tiny and slow. Brilliant minds created it, with some aspects of their design being completely original with no previous model to imitate.
• Bowie knife to Swiss army knife. When it was made, it had one feature and did it well with great ease of use. It might have come in just one color (black), but it was solid and replaced a time consuming manual system that people still remember (and hated). Over time, new versions added complex features and options. People forgot how little the manual system did and how hard it was to use, but they are seeing hard to use again and don’t like it.
• The integrity of the original design is compromised. When originally fielded, the design might have been based on a clear, simple design. For example, in the name of improvement, the thousand line C program that had a function per feature was replaced with a C++ program that was recoded, but not rearchitected.
• Orphans can get kicked around. The original authors and original stakeholders had some goals relative to functionality, scope, return on investment, suitability for a particular purpose, and probably most importantly, the software was of high priority. Once in maintenance, sometimes the level of resources, the amount of focus, the clarity of purpose, and the ownership and empowerment of the stakeholders floats. The new people know less than the original people, fail to respect their written or unwritten contracts about the software, and may make quick and dirty or slow and expensive changes, quickly earning disapproval from QA or resource/project managers.
• Moore’s law. If software was built to the limits of hardware (say 640K RAM of RAM and 10 MB hard drive), a few years later it may be remembered with nostalgia, but it is a relic.
• New paradigms. Pocket PC software that didn’t link apps with other apps can’t be nearly as versatile as an app that feeds its intents into a user selection from among several different programs (think photo sharing on an Android phone or tablet). That text based terminal with menus selected by typing a number and hitting enter is no match for an effective web page, not just from easy of use, but for inter-connectivity, scalability and maintainability.
• Competitive new designs shine by comparison. Being first can be a hard road, and to paraphrase Newton who said he stood on the shoulders of giants, it can be painful for software if it has competitors standing on top of it. Software that stops growing and improving is like people who stop growing and improving. The Honda Accord has been a Car and Drivers magazine top ten pick for over twenty years, but few people would pay the new car price for a brand new copy of a twenty year old car (except maybe a Brazilian build VW bug). In software, the problem is amplified because prices drive downward for many software based products.