I like the OP's summation that we should approach code reading as code decoding. My interest in literate code and readable code has recently accelerated in conjunction with my interest in code correctness. I think the way forward in both these contexts is through functional programming.
In particular I, and the IT shop at Tachyus, have chosen F# as the way to go forward for a number of reasons. Sticking to readability, F# (and other FPs to a greater or lesser extent) allow production code that "reads" more expressively in terms of conveying what the code is actually accomplishing to the reader (and to the compiler) rather than the frequently tangled instructions to the compiler on how to accomplish the task coming from traditional imperative and OO languages. F# also has some very useful tools to emit a form of literate code that produces publication ready HTML or MD, http://tpetricek.github.io/FSharp.Formatting/ (This project will soon be accepted as a top-tier project by the F# Software Foundation, http://fsharp.org/) It may not be to the letter of Knuth's idea of literate programming, but certainly in the spirit.
I did read some code lately. Actually I had to go so far as stepping through it in the debugger to properly decode it, http://jackfoxy.com/transparent-heterogeneous-parallel-async... (the code snippets here have tool-tips in my article, just one of the features available with FSharp.Formatting), but this is really the exception in F#. The vast majority of code is easily accessible to any programmer of reasonable quality (with proper introduction to FP) in any IT shop. The deeper functional stuff like Continuation Passing Style and Applicative Functors (e.g. heterogeneous parallel async) in most cases is already available in core libraries. And when not a literature search and/or getting in touch with the FP community helps.