You've clearly stated an opinion, but not an argument. You've also smuggled in the claim that an engineering manager who ships stuff is performing two jobs. I argue that engineering managers who cannot ship stuff are performing half a job. (I don't really, but you can see why this is a fallacy in both directions: it's an argument around definitions.)
Your opinion is the same on made in the article and is the consensus view. To me, the consensus view is there for a lot of reasons, one of which is that it's a common anti-pattern for formerly technical engineers to become managers and let themselves get drawn into the code at the cost of management. In all things, balance. The other, more general anti-pattern is to see a failure mode and then presume the diametrically opposed opposite is the global optimum. If engineers are prone to be bad at management because they get sucked into building stuff, then whatever benefits may come from that should to be ignored: they should abandon it altogether. (This is a common error in other domains, like the canards "ideas are nothing execution is everything", "you should never pick stocks, and only invest in index funds", etc.)
It also turns out it's much easier to believe that engineering managers who ship code are worse managers, because it means that you can feel good about deciding you're going to stop coding: you're doing it to do your job better. You already have so little time anyway. But what if it turns out being able to ship stuff actually helps you in being a manager? Now it's harder: you have to decide where to draw the line. And so, it's a much more difficult thing to come to terms with since it means there are no easy choices and you actually have to live with the fact you are always going to suck at this in one way or another.
I argue that, all other things being equal, having the ability to ship with the team makes you a better manager. The question is if that is true or not, and if so, at what point does the trade-off stop making sense to maintain that ability. Creating false hypothetical situations like "setting up an arbitrary HA database" doesn't prove much of anything about the actual, local, domain knowledge I'm referring to that you get by continuing to perform IC-like work alongside the team you manage.