As @rotweiller says, it’s an open ended question. I understand completely why you want this, but it’s very difficult to give you an answer because the majority of public code is built for a specific purpose, it’s not built to be aesthetically beautiful. And beauty is in the eye of the beholder anyway.
If it’s extremely robust, it needs layers of error handling, which will make it hard to read. If it’s extremely efficient, it’s often hard to read. If it’s general, it needs layers of abstraction to make it general, so again it’s hard to read. If it’s a big project, it’s hard to read. If it’s very successful, it is likely to be full of fixes, which will detract from readability and aesthetic beauty. Etc.
Given above, looking at big OS projects on GH as @Gigusek suggests is not likely to be particularly helpful from a learning point of view. Small projects, yes, though it would take a lot of digging. Big projects, no (though if they are ridiculously well documented and contain detailed descriptions of how they are structured architecturally that can work). For example, React is a huge project. How it works at a basic level is not massively complex, but React is both very complicated and very complex because it has to cover all the above points. Any large, successful project has years of accumulated cruft and thousands and thousands of lines of code.
That being said:
Underscore annotated source:
Backbone annotated source:
Note those three are from a guy called Jeremy Ashkenas who tried afaik to use literate programming as much as possible, where the code is just part of a written document that explains it. It is extremely difficult to do well, so there are not a huge amount of good examples beyond his libraries
Pell (WYSIWYG text editor, single small file)
Annotated Code - a Space Invaders game and a collision example (both for HTML5 canvas, single small files):
Top-down operator precedence (efficient parser of JS written in JS):