"most of eBay's functionality"
Do you realize what a ridiculous statement that is?
No. It's actually not hard. It was for an art reseller in Greenwich, CT, they held an art auction that was simultaneously online and in-the-flesh. I had account registrations, search (with image results), anonymous bidding, outbid notifications (via email), winning-bid notifications. I implemented the whole "what's the highest bid you would accept" functionality (also not hard). I did not write the frontend (a friend did that) and I didn't handle payments nor shipping (winners were expected to go to the physical store). Hence "ALMOST" all of eBay's functionality. :P
Either that, or I'm just a really good programmer under pressure (I pulled an all-nighter for that one), which I would not disagree with, I've basically been coding since I was 12 in 1984, so I would HOPE that I'm somewhat of a force to be reckoned with at this point. ;)
But I quickly moved away from it and I'll explain why.
I think that many programmers are starting to realize that the less "cognitive load" your language demands of you as a programmer, the better (the fewer bugs, etc.) Simple example, the recently-maligned "==" comparison operator has a very complex table of possible outputs (note that Javascript is also implicated here): http://stackoverflow.com/questions/7615214/in-javascript-why...
I mean, as a PHP programmer debugging code that used ==, you'd have to basically have that table memorized in order to successfully debug it. Contrast this with, say, Ruby, where only nil and false evaluate to false and everything else evaluates to true.
While there are of course "PHP best practices" that suggest === (which has a MUCH more sensible truth table), I find that much of the language is still simply not well thought-out and therefore is unsuitable for any large codebase. Sure, you can "get by" (see: Facebook), but you'd "get by" a hell of a lot better in a different (possibly a functional) language.
If you can't grasp all the cognitive load mentally, then you are invariably going to introduce unexpected states into your code (read: "bugs").
Lastly, a language should be 100% deterministic. Last time I checked, PHP didn't even consistently pass its own test suite. It literally has so-called "flagging" and "known-fail" tests which are just marked as such (and not fixed). I cannot explain how bad this is to build something else on top of.
So, yeah. If you're a great programmer, you can code almost anything in PHP (since you can handle the cognitive loads it introduces), just like you could code almost anything in, say, Brainfuck, or assembly. But as a great programmer, you'd be far better served by another high-level language (speaking as someone who knows and has worked with dozens of computer languages) which demands less cognitive load and therefore naturally reduces the number of bugs you will introduce.
I'll also plug John Carmack's piece on functional programming in object-oriented languages, because it's relevant: http://www.gamasutra.com/view/news/169296/Indepth_Functional...