• Perl is Unix distilled. Things like fork instead of threading, the IPC model, lots of functions, and a strong command-line, text-processing-filter heritage do come from its Unix background. On the plus side, learning Perl is a good way to pick up a lot of useful Unix constructs.
• Many functions are tied to their C counterparts. Just try to do any socket programming or file locking without man pages handy. Granted, there are modules to make this easier, but they still require at least passing familiarity with the C library.
• Dereferencing gets messy with multi-level structures. Using temporary variables helps here, and it's nice that you can drop the -> for multilevel structures, but wrapping layers of context braces around things gets old.

And where the author is wrong:

• Spaghetti Symbols. If the author is surprised that you don't use %hash{key} when accessing a hash element, he doesn't understand the symbols and shouldn't be talking about them. Period.
• It's hard to read code other people write. If the author has never encountered coding standard wars in any other language, he has very limited experience. Apparently, even languages like Java and Python allow programmers to choose their own variable names -- and they don't even have to make sense with regard to the problem domain and overall metaphor! Clearly, this is too much flexibility for a programming language.
• You have to read documentation to discern the arguments a subroutine expects. This is only a problem if you don't have code like the following:

  sub this_subroutine_takes_no_arguments_and_returns_nothing {
      # do something here, but nothing useful
  }
  [download]

• It's hard to install software on client machines. Though how he intends the client to install his software without being able to install any software is beyond me. (Yes, I'm being facetious.)

Update: I snipped a snipe at Python. It was unfair. If you're really curious, frag quotes part of it below.