I've over-engineered plenty of software in my time. Most of the time, it was because of boredom with yet another crud app.

An anecdote about rewriting:

I've also been involved in 4 successful rewrites. The decision to scrap/start over is rarely a good one. In my case, my team had inherited a bizarre suite of apps that combined VB6/C++. It was full of memory leaks, and had never been successfully deployed in the 3-4 years of its existence. We rewrote the entire suite in a year using .NET (1.x at the time). We (developers) went onsite to a bunch of our clients and watched them work, figured out what the system really needed to do, and made it do exactly that. The result was the first successful deployment the company had had in 4 years. It also sold itself in sales meetings, because it had been designed by watching users, rather than by guesswork.

So rewrites can be done. The question is: how bad is the underlying system? And how much easier is the problem to solve in technology X vs Y?

In our case, the underlying system was atrocious, undocumented, untested, written by a COBOL programmer who did not understand VB or C++ or OOP. And the .NET WinForms stack was vastly more productive than the C++ (and even the VB6) stacks we were replacing. The decision to rewrite was pretty easy.