OK, so maybe Chris didn't say "security is what happens between input and output." But I do. The truth is that a PHP developer really only has control over these two deceptively simple components of the application. Sure, there are scads of other types of attacks--attacks relatively beyond the control of the PHP developer, involving DNS, file system permissions, and (in the case of phpBB) other applications written in totally different languages (like Perl) running on the same hardware. The PHP developer, however, has a specific responsibility to make the "black box" he codes in as airtight as possible. And the way to make that happen is to focus on two domains: input, and output.
This raises another pretty interesting point: most PHP developers aren't.
They're systems administrators, network administrators, and sometimes CISOs for everything web-facing. Should they be? Can this go on in the enterprise? Can seasoned PHP veterans trust junior admins to do the job when it comes to setting up everything around the code they will write?
It is all too true that a secure application can be installed in an insecure way. The simplest case is, of course, with file permissions. Leave those config files read/write capable after you're done with that fancy web-based installer, and you're begging for trouble.
So where do we draw the line, divide up the responsibility, and make sure applications are safe end-to-end? In a well-run corporate environment, I still believe the developer should only have to focus on the security that happens between input and output. It makes a chaotic world manageable.
Frankly, I think Chris does well as one of PHP's resident security experts. As you can see, it's a heavy mantle to wear. One worn in lesser forms by freelance PHP developers often trying to be everything to every company. The truth is it is exhausting, and it has to stop. Time for developers to focus on secure development, and the rest of the enterprise to step up to do their part in sustaining a secure end-to-end web application.