Linting and automated checks are beneficial, but you are likely to get push-back from the team, as the checks will slow them down until they learn all the rules. Even so, I would even take it to the next level and make whatever IDE your team uses treat all warnings as errors, so your devs are forced to pay attention to everything the IDE notices.
Ask your team to support a policy that every change have at least 2 reviewers. That way, even if you end up looking at most of the reviews, you know someone else will also have to review the code. Also, publish the reviewer metrics, so the team sees who is pulling their weight on reviews and who is slacking. Even if someone is a bad coder, reviewing other code is a teaching experience for them. Teach your coworkers that it's just as important to ask questions on a code review as it is to suggest improvements. In this way, each review is an opportunity for bidirectional learning, which is why everyone needs to participate.
I agree with the answers which identify this fundamentally as a teaching opportunity. I especially agree with the suggestion to pair program. It sounds like you basically need to train your entire team. If this isn't your cup of tea, then time to look for a new job. Otherwise, pairing is probably the most effective way to skill them up.
Instead of doing code reviews by yourself, you should do at least some of them as a team. That is, schedule a meeting, invite several devs, and ask them to review the code, adding your comments and suggestions until everyone is on the same page. This lets you teach several people at once. Alternate between reviewing the worst code, which should fetch lots of comments, and your code, which should raise lots of questions ("Why did you do it that way? What does that line do?").
If you have a favorite book containing best practices for your dev languages, ask your boss to buy a few copies for your team, and ask them to read it. For C++, Scott Meyers is a very good authority. For Java, you have Joshua Bloch, etc.
It could be that your teammates see programming as a necessary evil, rather than their primary passion. There isn't a whole lot you can do about that, besides change companies. But if you feel they are on the fence, and they could be inspired to learn more, then you should try to see if there are relevant user groups that meet in your city, and invite them to join you there. They won't necessarily learn things that are directly useful to their daily work, but they should at least see the excitement of other devs about the language and libraries and frameworks. If you're lucky, some of that excitement will rub off onto your coworkers and motivate them to improve their skills.
It could be that some of them would really rather be doing something else, like Program/Project Management, or even people management. Have a talk with each team member to gauge where they are at, what their ambitions are, where they see themselves in a few years, etc. If one of them expresses an interest in a different role, and you think they are hopelessly far behind on coding, then gently encourage them to explore that role, and do what you can as far as recommendations to managers to make that happen. Then tell your manager that you want to be on the hiring loop for any new coders on your team, and that you are going to raise the bar significantly. Really, this is something that the manager should be doing, but they may lack the experience or motivation to do so. If this helps you get better coders on your team, then it's worth getting your hands dirty.
If your company has multiple dev teams, then you should either try to join the team with the best devs, or make your team that team. That means trying to manage the weakest coders onto a lesser team, and poach the good coders from other teams. Ideally, you should be working on the most impactful team (the one which delivers the most business value for the company). If so, then poaching good coders is actually beneficial for the company, up to a point. If you are not on that team, you should first try to get onto that team, and then build up your all-star squad.
You should, of course, recruit your manager into this task, as they will likely have much more influence and leverage than you do. You should explain that your team is actually delivering less than they would if you got rid of the weakest coders, because you spend so much time reviewing/fixing/undoing really bad code. But that they might be net positive on a different team, and so the company would benefit from a better alignment of devs with business projects. I.e., a little musical chairs. Of course, you want to scope out the work devs on other teams are doing, so you know which ones your manager should try to poach.
Naturally, the politics of this strategy can get quite messy, and it is not something everyone is willing to try. But at the end of the day, your company gets paid to deliver a product/service, so everyone who gets a paycheck should want the optimal configuration of workers + projects. Sometimes that means you need to make an all-star squad to work on the most important projects, and it may be that you are in the best position to help discover that.
Don't forget that the all-star squad also needs the best managers, too. So if you get your hands dirty with trying to reshape the org chart, make sure you know how good each of the managers are. It seems likely that your team has weak coders because your managers is not a good judge of skill, and there is perhaps a better manager on another team that you would rather work for. That is a pretty important thing to consider, especially when it comes to further advancement.