While this is tempting, it falls apart as soon as the development team matures and grows beyond more than a few people. What often happens especially in larger organizations is that bugs and/or changes come up and someone ELSE has to dive in and try to figure out what's going on. It's at this point that dense uncommented code or code that employs every preprocessor trick in the book becomes a huge liability. That "smart" developer just caused an increase in the time it takes to do code maintenance because the poor axe-wielding sap who has to look at it now has to spend a bunch of effort just to figure out what's going on.
Some of you may be thinking, "Then you didn't hire enough smart developers!" (for whatever definition of "smart" we're talking about here). To that I would say, "Maybe not, but I'd rather hire a solid, dependable developer who knows how to write maintainable code over some sort of savant any day of the week."
I've managed a lot of different developer personalities over the years, and the "smartest" ones nearly always produced the worst code for the business overall. In addition, while they were doing this, there were often other quirks that came along for the ride, like 'malicious compliance' with the design, or checking in three features you didn't ask for along with the one that you did. Sometimes it takes some uncomfortable conversations to get these people working with the team, and sometimes it's just impossible. In the latter case, this person just becomes a liability to the team and should probably be encouraged to move on.