I used literate programming for a multi-year project in a specialist field with a lot of technical details once. I was working solo but on behalf of a client, and I was working in Haskell to replace an earlier system I’d written in Python, so I wanted to leave documentation with clear explanations of how everything fit together for anyone who might have to maintain that system later.
The pros and cons of the literate style turned out to be refreshingly obvious. It felt more like writing a book than a program. That provided a clear narrative structure and led to thorough documentation, which really was very useful when revisiting areas that had been designed and implemented months or years earlier. On the other hand, it also required a clear vision, a coherent view of how the whole story could eventually fit together, to know where to put things.
For a project like that, IMHO it was a trade-off worth making, in the same sense that maintaining any good documentation (or a test suite, or build automation, or…) is an investment of time up-front that pays dividends later. I would be more cautious about adopting literate style for a larger project with a team of developers and a process where the system is developed in small increments with relatively little planning first. Editing literate code is also like editing a book: you aren’t merely changing the code, you’re also rewriting the story. You probably need a team who are committed to doing that well for the idea to work, though again this isn’t really any different to any of those other up-front investments.