It is generally about documenting and sharing problem-solving knowledge. As you note, this means one sort of thing for a computer scientist writing a paper, but something more pragmatic to an end user or business.

The software evaluated in this research was more of a traditional spreadsheet and GUI design, but other work looked at a test-based approach with something like Markdown. Something similar is going on in the data science community with "notebook" tools like Jupyter and Beaker.

I tried to use Babel, as mentioned in another comment, but found it too bloated and complex. My approach is pretty simple in comparison: code blocks can be annoted with a shell command, which they're piped into, eg.

‘``{pipe="python"}
echo ’Hello world'
```

Most actions can then be achieved in a regular Unix way (eg. by reading/writing files, calling programs from scripts, etc.)

Link: https://github.com/apiaryio/dredd

If real projects were maintained with the same level of human-to-human commuication there would be a lot fewer "legacy" projects. The U.S. is still using air traffic code from the 1960s. The Railroad retirement board has a huge legacy code base they can't maintain. Many other government agencies have the same problem.

In fact, you might run into the same problem if you ever get a chance to write code you wrote 10 years ago. You'll know WHAT it does but not WHY it does it. Literate programming is about writing down the WHY, not HOW.