The "point of excess complexity" is referred in English as:
OH MY GOD WHAT IS THIS CRAP.
The trouble is, this can apply to something thats actually simple, but is implemented in such a horrible way that you have the same reaction.
So telling apart something very complex from something very horrible can be difficult.
HOWEVER: What actually tends to happen to all software is process a bit like this:
Step 1: Have a nice spec, do a nice design, implement nice stuff. Everybody happy.
At the end of step 1: the developers congratulate themselves on the wonderful elegance of their design, and go away happy thinking "I have a wonderful legacy here for others to add things to in future, it will be wonderful and the world will be a better place."
Step 2: Some changes get made, things get added, new functions are included. The architecture and structure from Step 1 made this a fairly painless process. [But oops, the "cruft factor" just increased a bit.]
At the end of step 2: the developers congratulate themselves on the wonderful elegance of their design, and go away happy thinking "Gee I am so clever to have made all those allowance in Step 1. This went so well. I have a wonderful legacy here for others to add things to in future, it will be wonderful and the world will be a better place."
Step 3: More changes get made, more things get added, more new functions, a bunch of stuff gets changed, user feedback is actually being listened to.
At the end of step 3: the developers congratulate themselves on the wonderful elegance of their design, and go away fairly happy thinking "Gee this architecture is pretty good to allow so many changes to just slot in easily. But I'm a little unhappy about X and Y and Z. They could be cleaned up a bit now. But!!! Ahhh!!! I am so clever to have made all those allowance in Step 1. This went so well. I have a wonderful legacy here for others to add things to in future, it will be wonderful and the world will be a better place."
Step 4: just like step 3. Except:
At the end of step 4: the developers think: "This stuff that was so good is getting UGLY to maintain. It really needs some serious changes. I'm not really liking working on this. It needs refactoring. I wonder what the boss will say when I tell him it needs 6 weeks and there will be nothing for users to see at the end of this... but I will have got another 5 years of yummy future modification scope by doing this.... hmmm... time to go to the pub for some beer."
Step 5: A bunch of changes need to be made.
And DURING step 5 the developers say to each other: "This code sucks. Who wrote this? They should be shot. Its horrible. We HAVE TO RE-WRITE IT."
Step 5 is fatal. This is where the cruft factor has got so bad that the code can't just have a few more changes, it needs to have some BIG changes.
The trouble at Step 5 is the desire to throw it away and start again. The reason this is fatal is "The Netscape Factor". Go google it. Companies DIE at this point, because starting again means you start with about 50% assumptions instead of facts, 150% enthusiasm instead of knowledge, 200% arrogance instead of humility ("Those guys were so stoooopid!"). And you introduce a whole bunch of new bugs.
The best thing to do is to refactor. Change a little at a time. If the architecture is getting a bit tired, fix it. Add, extend, improve. Gradually. At each step along the way, test, test, and test some more. Incremental changes like this mean that 10 years later the current and original code are like grandfathers axe ("its had 10 new heads and 3 new handles but it is still grandfathers axe"). In other words, there is not much left in common. But you moved from the old to the new gradually and carefully. This reduces risk, and for customers, it reduces pissed-off-factor.