"How are you supposed to know the intricate details of another company's codebase and development process to be able to judge if they are really similar or not? You can only guess and hanging someone's job on a guess is pretty crappy."
I don't think the intricate details matter, I've worked for enough different companies to realise that the idea that some company is a special snowflake is an incredibly rare an unlikely thing. The odds of your company being in such a fundamentally different place that you're talking about drastic differences in delivery time, let alone if you take a number of samples is entirely negligible.
But apart from that many of the big boys actually do blog about their issues and state of their codebase, so the problems you describe are all incredibly well understood. You wouldn't realistically throw someone onto a project anyway and judge them immediately. There's always going to be a bedding in period with an employee and it's within this period that a lead will be taking on the issues within the team and the business, raising them and tackling what they can - few leads get to jump into entirely problemless companies and can attain maximum efficiency straight away. The question is how are they performing when those problems have been sorted, again, you're really conflating business issues with developer competence here, if you don't get business issues sorted then of course developer competence is going to be irrelevant.
"I fix code and I make users happy (because I fix the code and simplify their interactions), but that all costs time and pain and management typically just sees "not much movement"."
I hear you, I'm not pretending all business are perfect, but this wasn't about how do we survive in terrible businesses (hint: you don't, you leave them), it's how do we deal with problems of developer competence in general and my point is that we do that by having sufficiently competent and talented leads to weed out the bad, and help the good rise up.
"Welcome to the world of a real job working for a real company. Most companies have fucked up processes and policies."
I've worked in companies like those you mention and as I say, no amount of ability to gauge competence will help them - the fundamental problem you're talking about is not developer competence, it's about bad business practices, in that environment someone will always be looking for someone else to blame and even if they have an objective measure that you're the greatest developer in the world there will still be people who will ignore it because they don't want the latest failed delivery to be their fault. You can't resolve that as a developer, and being measured fairly wont fix or change it. A good lead might be able to change such a company but only if there are people in said company willing to fix problems, you're describing companies though where that's obviously not the case - as you said, "we hear you, but ...", in that case it's a lost cause until they either wake up to this or go bankrupt but realistically even if they wake up it'll be more than just a good lead dev they need to fix this, it'll be a good HR director, a good finance director, and a good CEO.
I learnt very early on in my career as a developer that you can't sit around in those companies hoping things will magically fix themselves - those companies aren't looking after you so you have no obligation to look out for them, don't feel like you have to stay for any degree of loyalty that they're not willing to pay back, and if you are talented as you believe you are then just move until you find a good employer. Then you can worry about measuring competence, because then you'll be somewhere that wants to get that right, and that's the company that needs the good lead.