First - different perspectives (i.e. bigger vs. narrow picture), Second - skills and competencies gaps.

First 'Special Conditions' - The gap between 'customer' and 'engineer' can often be quite large. Junior Engineers especially generally don't have an intuition for those things, and often 'the technical details' deal directly with feature orientation. There are legal issues, operational issues, so many 'bigger picture' things that are relevant. Cross-functional issues are definitely a thing, which is why a guy like Musk is probably managing a few layers deep, and 'very deep' in some specific scenarios.

Musk is a good example - because when he intervenes, because he has 'a lot of legitimacy' as 'founder and supposed genius' - people may not feel 'micromanaged' whereas if it were any other situation they very well might.

You may have a very complex code base where the architects, or Senior Devs who built the system need to intervene with a bunch of things to ensure consistency, communicate much of the 'unspoken' idioms that exist, and provide 'leadership by example' etc. etc..

For example, I trust my team members a lot more in the Java/Python domain, I almost don't trust anyone in C++ there are just so many ways to skin the cat, so many horrible anti-patterns, I've seen it all, so I like to take a really good look at the code. Often a second set of eyes helps.

On the whole, yes, micromanaging probably shouldn't be constant, but it can be consistent.

Second - there are skills (and communications) gaps in every resume. I'm literally managing a small offshore team right now, not getting adequate response when asking some specific questions. I've come to the conclusion they are literally not considering a whole pile of corner cases. I'm going to have to step in and hold their hands through a set of functions that they, for whatever reason, are not wading through very well. Fortunately, I have a ton of experience with this, and it will be ok.

This idea of 'if they are not good enough use someone else' is a little bit glib because far more often than not, it's not an option - either you have an incumbent team, budgetary/timing issues, and frankly, even if you didn't have limitations there, it's hard to evaluate people anyhow.

Finally - I will say that there are some situations where micromanaging probably is going to be constant. For very young and new developers on any kind of complex system ... they will need to have a lot of coaching and oversight. Even little things like tooling usage, which may not be 'formalized' because the team is in good sync, or the team is senior, but you have a junior who's not familiar with the git idioms on the team etc...

I think some of what you describe, i would consider to be "mentoring" not "micromanaging". I at least view those differently, but i can see how they can look similar in a lot of ways.