A published paper is supposed to present 'knowledge' in a clear and solid way. We know how to do that in, say, a physics text in a natural language, e.g., English, with text and some math.
So, now there's 'code' that is neither text nor math. So, in communicating knowledge, we don't know what role the code has. Fundamentally, the role is not promising: The code alone doesn't mean anything; mnemonic identifier names do not make a fundamental difference; with a lot of explanatory comments we are still a very long way from good examples such as a physics text.
In practice, programmers are often forced to look at code and discover its 'meaning', but that unfortunate situation does not mean that code should be in a published paper.
In simple terms, there are two cases of 'code' here:
(1) It is common to have a dozen or half-dozen lines of, say, 'pseudo-code' in a figure in a paper. The figure can help, but the paper should be plenty clear and solid without the figure. E.g., there was a long theme in much of the best in math that the writing should be so clear that no figures are needed; or, the content should not be in 'figures'.
But, I'm 'liberal' and can agree that intuition is important, that often there is an appropriate 'figure', that the reader should not always be expected to draw their own, either in their mind or on paper, and that, similarly, a few lines of pseudo-code can be helpful.
Still, the pseudo-code is not the solid, clear content of the paper.
(2) In practice, 'code' tends to grow quickly from dozens of lines to KLOC. Putting such code in a paper would be a bit much!
There is a real danger in computing: In nearly universal computing practice in writing and documentation, the content is not all in just text or math but in mnemonic identifiers and code, and that danger is real and a big step backwards in science. While it is clear where the danger comes from in computing practice, still the results don't belong in journals.
You mentioned Knuth's 'literate programming', i.e., his shot back at 'structured programming'! For the code itself, I was always in favor of his 'literate' idea. Although TeX is my main source of high quality word whacking, I never actually got through enough of his Web, Weave, and Tangle to write 'literate' code. The best I do is just use a good text editor.
In our AI project at Yorktown Heights, I tried to get people interested in literate programming and Knuth's tools, but people called it just 'pretty printing' and laughed.