It's almost always the CTO directly managing ~15 engineers. The CTO is always a man. He's always hiring a manager only because he doesn't have time for the 1:1s anymore. He never believes in hierarchies. The engineering team is flat, he tells me. They don't need teams, no siree. He's only interviewing me, he assures, because 1:1s aren't a good use of his time anymore.
Don't worry, he assures me, he'll still take care of all the architectural decisions. And he might even manage half of the team still, he hasn't decided.
That's usually about the time I nope right out of the interview.
In my experience, the desire to "delegate" 1:1s typically signals that team is raising truthful (and deeply troubling) problems, which the executive does not want to think about. Rather than think, they rationalize: claiming that consistently and privately listening to their subordinates is "not a good use of my time", "drama-filled", "not relevant to the tech", "isn't that what HR is for?" or some easy excuse. Whatever helps them coast until they jump ship next year.
Good on you for avoiding that mess, and for not playing along with their softheaded pretense.
The traditional path to leadership roles generally involve a stepped process from a role that's fully an individual contributor to one that has virtually no IC component. It's progressive enough that by the time you've stepped up to another level of management you've already grown accustomed to what you needed to let go of and what you needed to shift focus to, while having someone above you to essentially provide integration and regression testing as you acclimate to your new role.
A CTO-by-default skips that and goes from IC to "executive level authority and autonomy". They're not only managing people all of a sudden, but architecting teams and org structures. With little or no prior experience to lean on.
So they nope out of it - avoid org structure planning (and ensuing uncomfortable decisions) by keeping it all flat, bring in a people manager as a short term solution to the problem they created with keeping up with everyone, while also avoiding some of the messier side of people management. And seek comfort in the familiar work of system architecture and (maybe) keep directly managing the parts of the team that are the most capable of self-management and aren't as uncomfortable to manage.
Still a mess to be avoided, just as you said. But a mess that's rooted more in inexperience and discomfort than in arrogance and hubris.
Of course, differing degrees of stratification are still possible. The "Spotify model" decouples team leadership and cuts down a bit on stratification by distributing authority. But even then the model is not at all flat when you zoom out. And the smaller degree of stratification comes at the cost of incurring extra overhead resolving decisions amongst multiple stakeholders who have all been empowered over certain limited aspects of different teams/projects/services.