Yours is a common behavior for technical 'leads'.
Here's the deal. Yes someone with less experience will run into issues and problems that someone who has more experience will avoid. Why is this? Well because the person who has more experience has more experience with these issues and problems. So how can the less experienced person learn how to handle those issues and problems? By experiencing them.
Frankly, given your description of your team, I'm not surprised that the coders under you are lackadaisical when it comes to doing projects. You take the interesting and hard projects for yourself and you don't sound like you are above 'swooping in' on anything they're working on to 'fix it for them'. You don't trust them and from your description here it sounds like you don't respect them either. Why would they try hard in that circumstance? You aren't treating them like a team of peers who have less experience than you, you're treating them like a band of minions who should do your menial and boring tasks.
The goal of a lead developer on a team of developers should be multi-fold.
1) You should drive the overall vision for the code developed by the team including both architecture and general, high level implementation.
2) You should be available for mentorship with the goal of raising up the level of expertise of every member on your team. Being the 'lead' isn't about being a lead guitarist rockstar in a band, it's about being the coach of the team. You are not successful if the rest of your team is unsuccessful. As a lead, the description of the current state of your team shows that you are failing in that role.
3) Be open and nonjudgmental. At some point in your career you said some pretty stupid stuff. We all did. "Shorter cables improve performance" isn't all that stupid on the richter scale of stupidity. In fact, it is a legitimate discussion. You, who claims he is arrogant, use this as an excuse here of all places(where you are asking a question unrelated to it) to show off your own knowledge and poopoo the discussion. How did you handle it there? How will anyone on your team learn if the result of saying something is mocking derision? Why would anyone risk putting forward their own ideas or opinions in that environment? Frankly, at this point, I'm a bit surprised your team hasn't experienced a mass exodus to another team or another company.
In short your goal as the lead developer on a project should be to make your team and thus the project as awesome as possible. But right now you're hoarding the challenges in the guise of concern.
Let's be fair. There's no good training out there for being a lead. Also nothing you are doing(except being pretty arrogant yourself) is unusual or bad for a non-lead developer. Being a lead developer is a balancing act between being a developer and being a leader or mentor and programming as a field is pretty terrible at teaching folks how to be mentors in a healthy environment.
Your 'second in command' is desperately looking for ways to be relevant in the development process. Have you considered that he is nit-picking on particular topics because he feels that is the only place he can input feedback? You call him a control freak but, again, look at your actions and behaviors. You are unwilling to let go of anything you deem 'critical' OR let someone learn something from another team(why do you care if he asks what turns out to be a stupid question of another team if he learns something from it?) It's often said that to move up in a company you should find someone in the role you want and learn to do what they do. Your 'second in command' is emulating your behavior. Of course he wants to move up into your role eventually. That's the point right? That eventually he will learn so much from you that he can go be a technical lead on a team(whether this one or another one.) Why is that scary to you? Technical lead positions aren't like the Game of Thrones. There's more than enough room for every developer to be an experienced, technically proficient leader in the field without another having to die so their 'spot' opens up.
The TL;DR of this whole thing is that unless you give them a chance to both work on critical tasks AND learn from the mistakes that come up during those critical tasks your team will never be 'ready' for those critical tasks. If you are coding all of the core components of the project, you're being a rockstar and not a coach. I understand the desire to deliver the best, most perfect code. I understand the neurotic desire to have a handle on the entire project so that things come out exactly to your vision. I've lived both those things, almost all developers have. But those are things you have to start letting go of in order to effectively lead and develop your team. Some action items:
a) Are you having One-on-ones with a manager or supervisor? Personal development should not fall by the wayside just because you're more senior.
b) Have you taken part of management training? There are starting to be some excellent training seminars out there specifically for the developer turned leader.
c) Apologize to your team. Seriously. Whether you actually say it to them or whether you do it internally and apply changes. Your team is faltering and weak because you need to lead them differently. Start diivying up code. If you are the only thing driving core development on a project you are drastically screwing up your teams' bus quotient(the number of people whose, if they were hit by a bus, loss or departure would disrupt the company.) It's a sad truth but as you start being a lead, you should be coding less. Your time, especially with your team in disarray, should be devoted to getting your team up and running effectively.
d) Your team should be doing the following:
Regular code reviews where you should help guide the catching and resolution of issues as well as drive the implementation and design patterns of your choice.
Regular short meetings about their statuses.
Scheduled one-on-one time with a mentor developer(whether you or another 'more experienced developer'.
If any of these things aren't happening, they should be a priority.