Let me play the devil's avocate here.
Maybe all of your team, with the exception of that programmer, are the ones who are inferior, and he really is a brilliant programmer.
Imagine if, say, Linus Torvalds (let's pick a poster boy for accomplished programmer) for some reason fell into a situation where he is working in a team of moron programmers whose average IQ is 75. They would also not understand his code. "Nobody can maintain it but that guy himself! It is of bad quality!"
Nowhere in your question do I see the obvious complaint: that the code is incorrect, that it simply doesn't work. Those are the primary, objective indicators of bad quality. The rest are subjectives: hard to understand, maintain and so on. If the code does fail, why wouldn't you mention that? Are you by chance criticizing the fluffy subjectives because the code builds and holds up in execution?
Sometimes easy-to-understand code is wrong or inefficient, and making it right or efficient also makes it hard to understand. For instance, nothing makes concurrent code easier to understand than removing all the mutexes, semaphores and any code which deals with resolving obscure races, like re-evaluating states that might change and so on. Bubble sort is easier to understand than quick sort. A matrix multiplication is easier to understand than a fast Fourier transform. An H.264 encoder is harder to understand than one for motion JPEG.
Moreover usually code that really is hard to maintain in some objective sense is also that way to the person who wrote it. But in this case, you observe that nobody but that guy can maintain it. So in other words, someone can maintain it. Just not the rest of the team. So that guy has something the rest of the team doesn't: the ability to maintain that code. It's not like the code is has secret components: it's open to all of you to read. The excuse that he has an advantage because he wrote it is very thin, because the code does not make remote procedure calls to secret routines in his brain.
Without actually seeing the code from this person (and perhaps from the rest of the team, for the sake of comparison), there isn't any reason to believe that you are right, and that programmer is wrong rather than vice versa.