First off not all legacy code is "shitty." The main reason I am 10 or 100 or 1000 times more effective with legacy code is that I'm usually the only programmer the customer has talked to who will work with it. Everyone else has one solution: Throw it away and start over with [insert favorite cool language/framework/ideology]. So at least in my experience it's not that I'm 10X more effective, it's that everyone else is 0X effective because they won't even try.
It's easy and maybe fun to simply dismiss legacy systems as junk and shit and catastrophes, but when a business has a system that mostly works and they need some debugging, enhancement, improvement it's usually irresponsible to tell them to start over. When you do that you are telling the customer to throw away something that works, even though it has problems, and take a huge gamble on a new system that is 75% unlikely to even go live. You are telling your customer that your one hour reading of some code that you declare "shitty" is more informed than all of the cumulative experience of previous developers. You are telling your customer to change business processes, retrain staff, all on your word that you are more clever than the last team.
Imagine if you had a leak in the roof at your house and the first five people you called out to repair it told you to tear the house down and start over. And they told you that because the house wasn't built with the kind of lumber and roofing they prefer, or they don't think it's aesthetically pleasing based on their strict adherence to Frank Lloyd Wright's style. Or that whomever built the house must have been morons because they didn't properly label all of the wires and pipes. That's a story I hear about software systems every month.
The most important metric of software is whether it solves a business problem and adds value or not. What language it's written in, or whether the last programmer used spaces or tabs or camelCase or knew OOP as well as you think you do are not relevant metrics from the customer's perspective.
And since a lot of the code I work on is not actually that old -- in fact it's just as likely to be the unfinished remains of the last green fields team -- I can say without hesitating that the worst code to work on comes from programmers who are so committed to an ideology or language or toolkit they lose sight of requirements and the only goal that matters: adding value to the business.