It's not that people don't think you
can know security AND write PHP, it's that it's seen as very uncommon, largely because of historical context and PHP's ecosystem.
PHP, as you probably know, started as a really basic (if obtuse) preprocessor for HTML pages. It plugged nicely into Apache via mod_php, and was relatively simple and low-footprint to set up, so a lot of cheap shared-hosting sites set it up. For beginning/inexperienced web developers on small projects, this was great; you no longer had to go host your own Java/ASP/whatever web server to have server-side logic, now you could just use a text editor and FTP.
Unfortunately, this also meant that PHP attracted a lot of inexperienced developers -- the kind who haven't yet learned things like why you should hash (and salt) your passwords, why you should use stored procedures, and so on. (Editorial: it didn't help that the language itself didn't, at the time at least, make it obvious how to do such things.)
Granted, there were some developers who knew better who picked up PHP. But generally developers who have some working knowledge of web security best practices get that knowledge by working in the field -- which at the time, typically meant "heavier-weight" stuff like Java or ASP.
So with large numbers of inexperienced, security-unaware devs enabled to write webapps in PHP, large amounts of poor, insecure PHP code was written. So PHP got a bad rep, which only exacerbated the problem by creating a self-fulfilling prophecy that turned companies who could hire more-experienced devs off from PHP.
I haven't personally touched PHP in a long while -- I personally just don't like some aspects of the language -- but I've heard some steps have been made in the PHP community to make best-practices more easy/commonplace. Which is great! But the old reputation is still there, and bad reputations are hard to dispel -- especially in the corporate world.