At the risk of wasting my time with Humpty Dumpty:
OK, so first up I guess the problem is you've no idea what "escrow" is and so you ended up confused as to what key escrow could be. So let's fix that first.
Escrow is a service people or companies offer, the idea goes like this. Alice wants to do a deal with Bob, and Bob wants to make a deal with Alice, they're going to swap some of Alice's baseball cards for Bob's antique vase, but they don't trust each other. Fortunately they both trust Trent, a Third Party. Trent offers an Escrow service, both Alice and Bob agree with Trent that the baseball cards and the antique vase go to Trent, and then when he's got both things he'll send them to their new owners. If anything goes wrong, Trent gives back anything he received to the person who sent it and the deal is off.
In the tech industry the most likely set up you'll see is that investors are worried all the stuff they're spending a lot of money on at a startup is not material that a bunch of burly guys can pick up and put in a truck if the firm fails - instead it's in Git repos or Google Drives and if it falls apart they know it has residual value that could be realised but they're not technical people, they're money people. So an escrow firm says fine, pay us a bunch of money and make the startup sign this data escrow agreement, and then if they fail you activate this clause and we give you a bunch of USB drives full of source code and whatever else. The escrow firm has IT people who can do stuff like send over keys for access to a GitHub, who know the difference between an S3 bucket and a SD card, which the investors don't want to have to learn about.
In key escrow _your_ keys are held by a third party on your behalf. You can do end-to-end encryption if you want, but you're obliged to use this escrowed key. If the third party releases the key (e.g. because of a warrant, or an NSL, or because they're corrupt) then whoever gets it can now decrypt everything you've sent, or impersonate you seamlessly.
If your iPhone honors a secret Apple passphrase that's a _backdoor_. If instead Apple insists on keeping a copy of your passphrase in a safe at Apple HQ that Tim Cook promises not to open _that_ would be escrow.
Your objection that in DNSSEC "the roots can simply override that key with their own" also applies to any PKI, the whole _point_ of a PKI is that the trusted third party binds identity to keys, and if trust is misplaced they might falsely bind an identity to the wrong key. So the problem is - as I illustrated - that objections on the basis of DNSSEC being a PKI work just as well against the Web PKI. As a reason to prefer the Web PKI over DNSSEC they're ineffective.