Perhaps all this description is showing is that in many organizations there simply is a genuine need for a "Developer IT" support function with appropriate skills and resources, and because there isn't one, it's being done haphazardly by teams who aren't a good fit for it, as the author describes. If there's a few niche issues then that's solvable by e.g. dev training, but if the issues are systematic as the article asserts, then that's an organizational problem that needs an organizational solution. If your company can't ensure that devs are capable and/or motivated to troubleshoot issues that work on their laptop but don't in a real deployment, then your company needs some "internal consultations" mechanism to connect them to someone who does have this capability and can explain and/or fix the issues for them.
Responding to "Someone will always have to own that gap and nobody wants to, because there is no incentive to. Who wants to own the outage, the fuck up or the slow down?" with "Not me." is not sufficient, it's a very valid question for which any organization definitely needs an answer pointing at some specific people - if it's not going to be pure ops people, it's IMHO not going to be the feature-developing devs as well, that would likely need separate 'site reliability engineer' teams as some major companies do.
I agree that something needs to change at the organisation level in your case, but i think it's hiring and promotion. This "developer IT" stuff is part of a developer's job. Juniors won't join you knowing it all, but they can learn it from seniors on their team who do. If you are recruiting seniors who don't know this stuff, stop, and if you are promoting juniors to senior before they've learned this stuff, stop.
Responding to "Someone will always have to own that gap and nobody wants to, because there is no incentive to. Who wants to own the outage, the fuck up or the slow down?" with "Not me." is not sufficient, it's a very valid question for which any organization definitely needs an answer pointing at some specific people - if it's not going to be pure ops people, it's IMHO not going to be the feature-developing devs as well, that would likely need separate 'site reliability engineer' teams as some major companies do.