Inefficiency is only an issue when it matters, which is rarely. Even if a project is performance constrained, it's rare that the inefficiencies in the code-base will align well to the type of performance being optimized for(that would be just too lucky). You can speed optimize a memory constrained application for sport, but it's just for fun at that point.
However, new engineers usually take a while to ramp up to being overloaded like everyone else on the team, so its usually a good use of their time to have them work out some of the kinks other programmers wouldn't have made to start with if they had unlimited time and attention.
But that usually happen when a new engineer just out of the university start tinkering with "optimizing" and existing code base. They are usually greeted with a minefield of things that they thought where inefficiencies and turn out to be workarounds. Making the new and "improved" code break already working systems.
This is so so true. An actual real life engineering meme that I am super tired of. Hearing everyone around you !$%*! about other people's code is no longer the hip nerdy commiseration it once was. Now it's just an overplayed geek cliche that has worn a rut in my ears.
It seems I made a wise choice a few times when I extricated myself from projects with especially bad code bases without trying to euthanize them. Come to think of it, remaining members of those project teams did often look like zombies.