Julia Evans' approach works because she maintains the examples actively. The challenge for upstream man pages is that nobody wants to own the ongoing maintenance of examples that can silently go stale in ways that flag documentation doesn't. tldr-pages solved this with community maintenance, but it's a separate project rather than integrated into the man page itself -- which means you need to know tldr exists before you benefit from it.
Children don't learn to speak a language by learning all the grammar and conjugation rules first. They learn by repeating phrases they've heard before and they generalize. Usually we learn tools the same way. We see someone else using a tool, and we do what they're doing, and generalize.
That's not to say that man pages should consist only of examples. There are times when you really do need to understand how the tool processes corner cases and really understand how it works. But I expect most of us here can relate to the experience of opening the man page for a tool and being completely baffled by a wall of unfamiliar jargon. Most of the time you just want to see how to do the most normal common functions, especially when you're learning a tool the first time.
Perhaps it's overkill for power users, but most of the users will probably find it handy for the tricky find tool and friends [2].
I think other Unix/Linux users will find the literate programming approach as more useful, intuitive and less error prone ways to complement The Linux Programming Interface book [3].
[1] Cue Does It All, but Can It Literate? (22 comments)
https://news.ycombinator.com/item?id=46588607
[2] find(1) — Linux manual page:
https://man7.org/linux/man-pages/man1/find.1.html
[3] The Linux Programming Interface: