Ok, so I am first going to note what I think of this sitatuion. In my reply I will give what I think could be good next-steps.

But here is the problem. The overall efficiency of the FE team has doubled and most importantly regressions have become almost extinct.

Micromanaging is managing to such an insane detail that it harms production. Basically the idea is that this senior would have their attention so spread out, that the decisions they make are worse than what individuals would do.

If this guy is "objectively a micromanager" that implies that he is doing worse decisions than what an average developer of that level would do. If productivity is increasing, that speaks badly of your colleague's ability, basically showing it must be underaverage and replacing them with a random hire would be an improvement. I doubt that's the case though, but lets be clear: what you're saying, as numbers, is that if it gets to the team or the senior dev, it seems you want to keep the senior around and switch the team. Lets go on to understand more of the problem and see if there's a better solution.

Now in my mind apart from it being boring and a bit annoying for the juniors, it is also very bad for their growth.

What do you think is the growth for juniors? What do you think is the level and tasks a junior should have?

Junior engineers have a lot to learn: they need to improve their coding skill to which they can "fluently talk code" (that is they don't think about how to write something, they just do) which is something you only gain with a lot of practice writing a lot of code (if you come out of a solid university program, I'd say about a year to two extra of full-time coding should be enough, otherwise this may not be the career for that person). They are also learning to be profesional, work on a profesional environment, interact with managers, understand the structure, realize the shift from "solving problems to prove you've learnt the lesson" to "solving problems that a business has", and the mindsets needed, as well as grok all the pragmatic aspects of programming you don't really think of when you first learn: testing, release systems, production systems, marketing requirements, domain models, etc. etc. etc.

The other thing is that it's easier to learn by seeing a good answer and doing it, rather than iterating on a myriad of mistakes (you could spend your whole life never learning the non-trivial lessons in the right way, and be stuck in a 1st junior year for 10 years). The juniors may think they could have done it themselves, but you know what? I'm calling Dunning-Kruger bullshit. There's no way someone with less than 2 years experience understands the implications of a design after 12 different people have iterated on it for 8 years.

So what you do is you give Juniors a lot of great models to follow, very detailed. Later they'll be able to make their own decisions, make mistakes and realize why those designs given to them were the way they were.

Now lets move on to mid-engineers. These ones are a bit more challenging, you still want to invest and have them grow, but you have to give them space to make mistakes. Here though I still sympathize and understand where the senior dev you're speaking off is coming from.

A lot of times, when I start a new project, I hog a lot of the coding and work setting things up, I basically set a foundation of thinking models, paradigms, strategies and conventions. I make spaces to expand and change, and leave key "load bearing" pillars of code done very well and resilient to future changes (~80% of the code is "good enough" sloppy, but there's a 20% that I know will be the main source of bugs if not done with care). This is also true when I get to a project that has serious tech-debt issues, or is struggling to work well.

And here's the harder thing on the second scenario: I am working with the team that let things get this bad. So I am trying to subtly, through Conway's law, through showing better ways of doing things, through specific requirements and expectations on the work of teams, to make the team's culture and practices change to something that will not go back. This is a lot of pressure, and this is going to mean making a lot of the engineers work on things that they think don't matter, and make them ignore things that they think they should care for. I expect pushback because ultimately I am telling engineers they are going wrong about the problem. Again what I do here is have numbers I can show to demonstrate it, and let people grow and improve, without accusing anyone, using passive voice, just saying "these practices have resulted in an improvement" and focus on that: the future and improving things. But egos will get bruised because people will realize the implicit thing: they were doing it wrong and it was the source of the problem.

And again, this isn't to speak ill of engineers. A lot of times they gained these practices when the project was in a dire situation and things weren't great. And those practices helped improve things to the point that they aren't needed anymore. Sometimes they just never get the training or vision to learn from this.