More bad stuff:

• Basically only two kinds of variable scope: global and local to a function. That means that if you have several PHP files that are intended to be used together, and just "do things" that are not wrapped inside a sub 'er, "function"), that they'll stamp on each others variables. There's no way to limit a variable's scope to "just this block" or "just this file".
• Guess what value the variable $x will have after the loop finishes?

  # PHP code
  $x = 'foo';
  $row = array('a', 'b', 'c');
  foreach ($row as $x) {
      echo "$x\n";
  }
  [download]

  I'll tell you: loop variables are not localized. Stomp stomp stomp.
• No support for placeholders in database access *. That means that you have to produce literal SQL strings to execute, by incorporating the data in the SQL statement. It's slow if you have to do this many times in a loop. But, in order to prevent people form accidently creating invalid SQL this way, GET and POST values are pre-addslashes()-ed by default! Talk about doing a patchup in the wrong place!

Update: broquaint pointed out that PHP does have support for placeholders, which is a good thing. I must say that none of the PHP developers I've spoken to, has ever even heard of them. So use of placeholders in PHP doesn't seem very commonplace. However, my complaint on the automatic addition of backslashes on special characters in form variables still stands, which was my main gripe in that point.

The phrase "It has about as much support for placeholders as perl does natively" is one I just cannot grok. Perl does not have native SQL database support without DBI. DBI is the way to access SQL databases in Perl. Using placeholders is one of the first things you learn there. OTOH, AFAIK they're hardly even mentioned on PHP's manual website, and only under Oracle and ODBC. Don't you just hate it that every database has its own kind of access functions.