Jupyter is a tool to do some exploratory interactive programming. Most notebooks I've seen in my life (probably thousands at this point) are worthless as complete programs. They are more akin to shell sessions, which, for the most part, I wouldn't care storing for later.
Of course, Jupyter notebooks aren't the same as shell sessions, and there's value in being able to re-run a notebook, but they are so bad at being programs, that there's a probably a number N in low two-digits, where if you expect to have to run a notebook more than N times, you are better off writing an actual program instead.
This is how all intellectual work proceeds. Most of the stuff you write is crap. After many iterations you produce one that is good enough for others. Should we take away the typewriter from the novel writers too, along with Jupyter notebooks from scientists, because most typed pages are crap?
Can you possibly make Jupyter notebook act like a module in a program? -- with a lot of effort and determination, yes. Should you be doing this, especially since the alternative is very accessible and produces far superior results? -- Of course no.
Using your metaphor, I'm not arguing for taking the typewriter away from the not-so-good writers. I'm arguing that maybe they can use a computer with a word processor, so that they don't waste so much paper.
Some people like challenge in their lives... and I don't blame them. For sport, I would also rewrite some silly programs in languages I never intend to use, or do some code-golfing etc. Literate programming belongs in this general area of making extra effort to accomplish something that would've been trivial to do in a much simpler way.
That's why I'm stuck in Tolstoi's War and Peace. You have to know French to get past the first few pages.
But, more to the point of literal programming: it's not the only tool that wants programmers to write some sort of a plan or a sketch of the code before writing code. A much more popular technique is TDD, which, again, wants programmers to write something informally first, and then formalize it later in code. And, as with literal programming, my experience was that it's not helpful to the point of being a distraction.
There's a good reason to think that some sort of a sketch or a blueprint might be useful for the future program. It works like that in many other disciplines. Artists would make sketches before painting the picture, engineers make blueprints etc.
I think that the reason why literal programming doesn't work is because unlike a sketch or a blueprint, one has to carry it on forever (and propagate back the changes, once they are discovered) as long as the code is being worked on. It probably would've worked better if it was some sort of a plan that can be abandoned at any point, something to give the development the initial push, but not requiring any further maintenance.
I always wish they would take a hint from Emacs org mode and make notebooks more useful for development.