(a) philosophically, categorically refuses standardization ("There's more than one way to do it")
(b) has multiple meanings for each function call("context")
(c) is chock full of single character "special" variables that don't behave like normal variables (and the meaning of something as simple as "evaluate this variable" can change via tie() anyway)
(d) has an interpreter that "guesses" the meaning of a construct rather than a clear language standard... the motto is "try it in Deparse and then you can find out what it does"
(e) provides multiple features to allow programmers to alter the meaning of the code being run based upon run-time computations (autoload, eval, symbol table manipulations, coderefs, code filters, ties). Code can't be read in isolation, because what it means depends on what's been executed previously.
(f) can only be probabilistically parsed by anything other than the perl interpreter, because of point (d) above, leaving code management tools to guess and pray.

If that doesn't qualify as "write only", what language does? The only languages that I

The only way to make perl less "write-only" is to write coding standards to prevent abuses, and scale it back into a manageable language again.

However, part of the point of a higher level language is to enforce good coding conventions automatically: for example, no access to pointers in Perl means no pointer errors, even though programmer discipline, and "don't hire monkeys" should prevent pointer errors in C and assembly language. But traditionally, it hasn't.

Replacing human error with machine precision is exactly why we moved from assemblers to compilers in the first place. Then again, I'm sure a ton of people will now protest that "Assembly Language is not write only", and only a "j***a**" would think so...

*sigh*