I think you missed the point. Maybe the dude writing the crap code did get kudos for time to market, but now the code is not in a position for the new feature to be added at the speed the business needs it. That is entirely on the first guy, but the person who comes behind will be measured as if they were responsible. Also, most businesses expect to continue the velocity of the first rounds and have zero understanding of the tradeoffs that were made. All they understand is now features are taking longer.

To go back to your analogy let's assume the repair shop does exactly what you ask, knowing your car is going to throw a rod very soon, but they say nothing because you didn't ask them about it. The next day, you're on your trip and now you have to hire a tow truck and the repair costs 5x as much, plus you never got where you were headed. Depending on your intelligence level, you may not connect the dots and realize that by getting you your car 2 hours faster the repair shop cost you several thousand dollars and ruined your trip, so you might happily write them a glowing review.

The thing is, businesses tend to overestimate how much longer quality takes and underestimate the impacts of low quality code. Often lower quality code is no faster to produce when you count in the fact that it goes through more rounds of QA. But often business doesn't measure that.

But you're right that ideally I would work for an employer that is more aligned with my values. The problem is there's a pervasive misunderstanding of how bad the impact of poor code is (actually good code is much faster in both the short and long term), so it's difficult to find companies that are aligned. Usually I do better with convincing ordinary companies through delivering results that are so good they don't need to be measured.