Having senior people write all of the code shuts down your ability to create new senior people. If you have a bimodal distribution of employment longevity for your devs, this may be why. If nobody gets promoted for three years because you can't trust new developers with the code (until they've memorized everything) this is probably why.

Nobody wants to touch the lead's code. The more of it there is, the slower things go. Or the more workarounds/end runs (duplicate functionality) you find in the code. It's best if the leads only stick their fingers into code that absolutely has to work, has a low expected rate of change, and relates directly to architectural or (better) operational concerns. Everything else they should keep an eye on, insist on quality, but otherwise butt out.

People write code that seems obvious to them. Very, very few of us make a conscious effort to do much more than that. You can write a great deal of solid code that is still write-only. Too much of this, and it makes it difficult to improve your bus numbers, and grooming people for growth is a huge investment of time, energy, and social capital (if you can do it at all). Rather than bringing the whole team up, people play favorites, because that's all they can afford.