Rather, they are a testament to the difficulties of replacing running software and the problems of managing any software project.

The original software was written in an older age for older hardware, it thus must have much simpler functionality. Because the ability to build larger systems may not have existed back then, and the ability of the hardware to cope with anything beyond the basic functionality was perhaps minimal at best. Given those requirements the devs banged out a simple system which then sat in constant use for ages (the best form of testing) and was patched up over time.

Now along comes a big, well funded project to replace the aging old system. Of course mountains of new requirements get piled onto it (because computers are so much faster and our programming tools are so much more capable). And then the project goes over budget and over schedule, the death march eventually produces a barely functional replacement and of course it's full of bugs because they cut corners rushing to get the thing shipped and nobody seemed to appreciate the enormity of the testing and defect removal needs for a new more complex system to match the robustness of a system that has had literally decades of real-world testing to facilitate defect removal.

But note that this sort of trend applies regardless of the talent of the original developers. Even if it took 5 years for that original system, simple as it is, to become robust it'll still look like a work of genius compared to attempted re-writes that fall victim to all the problems listed above.

  How many of us have written software 
  that will be used 30 years from now?