TeX benefited from literate programming because it was written in a higher level assembly language.
(Also, it was written by someone who liked to write books, and if a book was about software, he wanted to integrate the writing of the book and the software.)
Better than literate programming is to write code that explains itself. Don't write two things, one of which executes and the other explains it; write an explanation which also executes.
In other words, don't desperately separate and literate; instead, lisperate!
Are you talking about MMIX as "higher level assembly language"? MMIX is the (a?) programming language used in TAOCP. For Knuth it was a purely theoretic thing. Other people have implemented MMIX by now.
If the choice is testable, you can write a test case for it. B and C don't work because they break the test case; A is required.
If the choice isn't testable in any way, it's not worth commenting on.
In general, in many programs we can find algorithms that could be replaced by better ones (such that no test cases break). There is no need to explain why that is the case; all the various possible reasons for that are obvious, and it doesn't matter which ones of them are true.
No, code cannot explain itself. No code will ever tell you why this algorithm was chosen, what are the unobvious consequences of this choice, and which papers should be cited.
(Also, it was written by someone who liked to write books, and if a book was about software, he wanted to integrate the writing of the book and the software.)
Better than literate programming is to write code that explains itself. Don't write two things, one of which executes and the other explains it; write an explanation which also executes.
In other words, don't desperately separate and literate; instead, lisperate!