The term beautiful code is a very vague and abstract term.
Its easy to figure out what it represents, and what it means, but it should never be seen as more than a secondary goal.
It reminds me a lot of the code coverage metric. When you get the number high enough you can relax and go onto something else. Having a codebase with about 80% coverage is great, not bulletproof, but enough to chill and do other things. Having 40% coverage is pretty scary and should encourage you to get that number up.
Point is just that code coverage is only really meaningful if the number is low. So don't let it be low. When the coverage rises to a certain point, move on to something else.
Similarly beautiful code is great. If you have pretty code, great, move on to something else. Don't stress too much about it. You'll never ever hit that 100% mark, and if you do you'll find you've focused too much on what it reads like, or what it looks like, and not enough on what it does, or how it does it. So get to a reasonable mark and then stop.
But if your code is fugly, if its a giant convoluted mess of spaghetti code, if it physically pains you to open the file, if you have no comments or documentation etc etc etc then fix it. And do it asap.
You'll find over time your code base ends up generally cleaner, generally brighter and generally more beautiful and more importantly more usable when you focus on making it less fugly. Writing beautiful code is not a one step process.
There is no magic philosophy. Its 1000 smaller steps all done together, all of which serve a concrete purpose that has nothing to do with how beautiful the code looks. But, when you serve them up all together, they form beautiful code as the sum of its parts. Like voltron. Or captain planet.