But you do *often* share various car parts across decades of new models, because the marginal gains of a new design are not worth the expense and risk, and new designs are often variations on the old (sports cars have used double wishbones for a long time, the thing under a 1990 Miata is not very different than a 2016 Ferrari)
Whereas in software we do entirely new designs monthly!
Which, maybe is a bit too often. Maybe we should wait two months.
Ah, but now we're talking suspension ;-)
I do agree that sometimes software is needlessly thrown out wholesale. There's a balance to be struck between completely rewriting something and reusing code. Unless the code was written with systems in mind which had very different constraints, possibly making a from scratch rewrite faster performing and quicker to write, there is probably a happy medium to be found. One where you examine and replace individual bits of code, then see if that has any implications on other bits of code that it touches or was touched by.
The end result may still be a complete re-envisioning of your "wheel", but in an evolved way. Not the "let's throw out old code", failing to learn from it, and then building a replacement that's not meaningfully better in any way
If you're going to "reinvent the wheel", at least make sure you study the thing you try to replace and see what it did well. Formulate exactly how you're going to improve on it. Chances are people - in their haste to replace wheel A - forgot what wheel A did really, really well, so they make a wheel B that doesn't have some of wheel A's quirky bits. Fine, except it also doesn't have the things that made wheel A passable enough to grow a user base to become annoyed by its limitations. It helps to ask the question what problem wheel A initially set out to solve, imperfect in its execution though it was.
Do those assumptions still hold? Have advances been made that render those assumptions obsolete and would you end up perpetuating this quaint old assumption if you write a wheel B that's still pretty much wheel A? Are there new constraints to keep in mind that have surfaced since wheel A's initial design took shape, or that wheel A neglected to address? If so it might be useful to keep that in mind, lest you end up with a great wheel B that just happens to be vulnerable to security issues which were old 2 decades ago.
Notice we're talking about two different models here:
A) Write an 'improved' competitor from scratch, whether or not from the same vendor.
B) Incrementally upgrade existing code for new realities
In both cases it's good to look at what came before. Often the new requirement is just bolted on. Even in case B I'd argue it's a good idea to really go through the code base once in a while - particularly if it's 5+ years old and still looks serviceable. There's bound to be gotchas that made sense at the time but will bite you in this day and age.
So I'm not saying throw everything out all the time. I'm also saying to never throw something out. There are instances where both would be the right thing to do, but there's often a good middle ground to be found that's regrettably overlooked by many.
* See also: The web's infatuation with the new shiny, same as the old shiny except the O'Reilly book has a different animal on it. And maybe it's frustrating to use in a slightly different way.