There is Org Babel in Emacs that can be an alternative to jupyter notebooks for literate programming (research/devopsy tasks). It is more powerful in some aspects and weaker in others.

I think that statement is also a great concise explanation for why literate programming doesn't really work in practice.

For something as complex as the Linux kernel, there is no single document that is going to explain the entire system to anyone who reads it. For a start, different people need different levels of explanation. Someone fresh out of a JavaScript bootcamp is going to need a very different guide to Linux than someone who's spent years working on the Windows kernel and just needs to know what's different and what's the same. Moreover, the further a person is from understanding how the Linux kernel works, the more iterative the explanation will need to be: first setting up the broad concepts, then explaining these concepts in more detail, then clarifying these details with more precise examples, and so on. If these layers of explanations are bound to code, then the person who needs less of an explanation will end up skipping parts of the codebase (assuming they let themselves be guided by the literate documentation). If the explanation is not bound to the code, then that's not really literate programming, it's just documentation.

The other issue is that even two different people with similar levels of skill will often want things explained in different ways. Partly, that's going to be things like the analogies they're used to, and partly that's going to be a question of what they need from the explanation. A document "The Linux Kernel for the Data Scientist" will probably look very different from "The Linux Kernel for the Systems Engineer", and both will be different again to "The Linux Kernel for Project Managers". A huge part of technical writing is understanding precisely who your audience is, and in literate programming, your audience kind of becomes "everyone", which is too large an audience. The advantage of separating code and documentation is that you can write your code for a much more restricted set of readers, but provide a bunch of different additional guides that are each aimed more precisely at a target audience.

I think literate programming can work for programs that are primarily intended as tools for teaching (because then the whole application is designed to be read by a specific target audience, and can be written from that perspective), but for general-purpose applications, particularly more complex ones like the Linux kernel, are better served by separating out the different documentation concerns.

This is how I see version control. Adding another dimension to every line of code, that explains the why that code is that way it is.