The main idea behind the "do one thing" is really composability: by doing one thing, your program can be used to provide the functionality for other programs to form applications. Patch uses ed because it needs to edit text and ed provides the text editing functionality, but ed can also be used interactively or from a shell script or by some other program. This is because ed doesn't care how it is called nor where the commands come from. This isn't enabled by its simplicity, but by its design to be composable: it would be a trivial difference in terms of complexity (and indeed there were similar programs in other systems that did exactly that) to ask the user for a filename upon launching it. But that would only make it useful as an interactive program (which is also why the Unix philosophy warns against captive user interfaces).
Ironically, Microsoft's COM and OLE followed that idea better than anything on the graphical side of Unix ever did (except X11 itself, but few programs ever took advantage of it - the best case would be applications meant to be "swallowed" inside docks - docklets - and panels, but those are very task specific). However there is also something to be said about being simple and COM is anything but simple.
That philosophy could also be applied recursively; Perl should do just one thing; it should be a good scripting language. The Perl JSON module should just do one thing; it should be a good JSON encoder and decoder. That doesn't mean it should be simple; the JSON module should have as much complexity as necessary to make it a good and useful tool.
I do recognize that my interpretation isn't a great _definition_, because you can construe most things to be UNIX-y if you just expand what "one thing" it should be good at enough, but I do think it's useful to keep in mind when designing something.
That said, I have never written Perl (other than a very tiny amount of Perl 6), and don't know exactly what about it convinced you, but I wouldn't mind a discussion about it if you clarify.