Twitter serves their service to the entire world, with multiple layers of systems working in conjunction in order to make things work smoothly. A new engineer that has not been working on it for no more than a couple months would likely be unaware of how the different systems communicate and interact. A change like this will have have a lot of unintended consequences, and not having a senior engineer with lots of context leading the change will undoubtedly cause these kinds of issues.
Having a senior engineer with a lot of context is worthless if the work environment does not promote open communication. You don't want to be the senior engineer or leader who shows "poor judgement" by opposing the mercurial owner "for no reason" if you're overridden and the feature launch succeeds without a glitch; no one gets fired for implementing a request that came straight from the top.
This is why non-rushed, scaled roll-outs are essential for large system: had they tried this on 1% / 5% / 10% of random traffic first, they could have caught this. Yet again, if the directive to roll it out to production came from the very top, you set that gate to 100% immediately.
Twitter could be packed with extremely skillful senior engineers who don't understand the product well enough to predict complex outcomes of planned changes.
The one's left don't know all the code (how could they?), but were forced to change many things about the site at a "just do it" basis. This error didn't happen because someone was too stupid to remove the code, it did happen because the connection to another thing was removed and the failsafe on the landing page doesn't have exponential backdown built in, not something you can necessarily know or investigate before, when an executive breaths down your neck and wants you to just do it.
This is about the new managment, not about engineers.
They are potentially more vauable than the 100x engineer who has intimate knowledge of how googles shipping container datacentres work.