You're not a 10x engineer. You're a 2x who hasn't figured out yet how to teach other engineers what you know. It sounds like it's past time you got started, for your own sake as much as that of those around you.
That's not a fair characterization. Did you read his post? He said,
> In my direct team of 10 people, myself included, I have completed 71% of all story points in 2022
So on average, the other team members complete about 3.2% of the work, and he does 71%. At least in relation to his team, he's ~20x in output.
Without further context, though, those numbers are meaningless. There's been spans in my career where those sorts of numbers would apply to me but not because I'm an nX developer but because, e.g., a lot of the stories were related and it made sense for me to do them as part of an ongoing sequence whilst the others handled, e.g., bug fixes in other areas.
This doesn’t help people grow in the long term, though. It builds dependence on you and your skills. You can quickly become the bottleneck (unintentionally!) and the “smartest guy in the room” by virtue of handing out answers and hoarding domain knowledge instead of developing the people around you.
I don’t know you, so I don’t know if this is what’s going on. If it sounds familiar though, I have two suggestions. First, read The Phoenix Project and pay attention to the character arc of Brent and see if his journey rings any bells. Second, next time someone comes to you for help, or asks for your opinion, instead of giving them the answer directly, coach them through the problem solving process by asking questions until they arrive at the answer themselves. This will help develop that problem solving muscle that they need and help them to level up.
It's reasonable to expect it to feel weird at first, especially if you're not used to or comfortable with working closely with others. The good news there is that that gets much easier with effort and practice, too.
It can be easy at first to want to just do stuff while people look on. You want to watch out for that; it can be gratifying, but doesn't much help anyone learn.
The key, I think, is instead to find the right balance between talking through your analysis of a problem and how you work through it, and giving whoever you're working with opportunities to practice doing the same with you as a sounding board and counselor.
It sounds basic, maybe, put like that. But it isn't; "problem" here can mean anything from "implement a function to add two numbers" to something that extends across an entire software stack and touches every level of infrastructure. It can be building an MVP from scratch. The point is that it's what your current mentee is ready for, or maybe just a little past that if you think they've got a habit of undervaluing themselves and could use a chance to build some confidence.
Above all else remember that your essential purpose as a mentor is to make yourself no longer necessary to the person you're mentoring. You are trying to engineer yourself out of this job, because to have done so means you've succeeded.
You needn't worry too hard about what comes next, I think. A good mentor never wants for work, and it's a surprisingly good way to keep your own skills sharp, because you can't teach like this unless you really understand what it is you're teaching.
Too, demonstrating you can work well with other people this way makes it very easy to continue into management, if that's what you want - and it is worth thinking about that, at our age. Some folks stay great engineers all their lives, but not all. And hell, after a few decades doing the same kind of work, some folks just find they want a change.