I try to, but that's beside the point. What passes for 'easy to understand' when you move past 'flat text files as a representation of code' and how is it better?

Good naming practice. Either pull each line of non-trivial code out into it's own method, or assign the output of the code to a variable that tells you what it's doing.

If you find yourself repeating an assignment, pull it out into a function and remove the duplication.

Rinse and repeat until everything in the file is assigned to a descriptive function or variable. Doing this with someone else's code gives you a feel for how to do it with your own.

This a total non sequitur. What does this have to do with alternatives file formats for code?

What do alternative file formats for code have to do with readability?

At the moment I can open up source code in almost any language up in any text editor. It just has to know the encoding and vomit out characters I can comprehend and get the line breaks right. I can print it out and have a hard copy which represents what was written by the programmer. Send it and receive it by email and read it.

Code which can be represented as plaintext is versatile and portable and, more importantly, has its comprehensibility decoupled from any specific company, or project or group providing the necessary tools to make it human-readable. If an alternative file format isn't natively human-readable then it is by my definition less readable regardless of the standards put into writing the code itself.