If you require that person to also be the most technical person in the room at all times, whew. Either that's a very tall order or recruiting/hiring needs work. More technical than that person who's spent a career getting absolutely ace in their niche? More technical than the data scientist who spends 8 hours a day digging really deep into bleeding edge neural networks?
I'm totally with you that a manager should be able to understand the thing they manage to a certain (not too shallow) depth, but you hire experts for a reason, and in ordinary circumstances, and in an ordinary IT department, a C-level manager should not strive to out-expert the experts under their purview. That kind of micromanagement/smartassery will just drive away the experts, and then you need a new CTO and new experts and maybe go bust.
Exception to the rule: If you're in a startup where the IT departmend consists of a CTO and one guy remoting in from Bulgaria who runs the servers and is really really cheap, you as the CTO actually should be the most technical person in the room. But once you hire the first actual expert, you should take a step back and get more big-picture-y.
Basically I set the team values, priorities, and processes, but I do need a lot of my team to have deeper knowledge of certain things than I do.
For a decent size company I'd hope the same, but with the proviso that over time any specific industry experience will degrade to a more general understanding, which is fine.
And if they don't have the experience they delegate.
So bearing in mind the original story, either the CTO should be at least decently technical enough to avoid composing SQL like that commit does, or the CTO should not be committing code in the first place.
I think we see a lot of tech company failures when the CTO is just a manager type that doesn't understand the technology and doesn't have the ability to contribute to it.