> The one advantage I see is a ton of existing code and programmers to draw on

I would not consider this an advantage per se, because exactly like C, it's difficult to find a certain type of programmer who cares about things like performance or has a real understanding of what is happening when their code executes. I see the same thing happening in the Node.js community. (PHP, C/C++, and Node are my primary languages right now, I'm certain the same thing happens everywhere else, too)

> Certainly add anything that you think are advantages. I try to give everything a fair shake. ;)

How gracious of you :P As I said, I feel I'm not really representing the PHP community or the direction it's heading right now, but here's my view:

As far as your points 1, 4, 6, and 7 are concerned - it's pretty much on par with other dynamic languages such as Lua or Ruby. My knowledge of PHP VM internals is limited, but as far as I saw last time, it's not fundamentally different from Lua's. There are some big WTFs in the syntax area, which I think is one of PHP's weakest points to begin with, but as far as expressivity and concision is concerned it's relatively powerful. Rubyists tend to talk about how speed is not important, which I disagree with, and PHP has never let me down in this regard.

As for 2 and 3, well it's a dynamic language with an optional class system. As such it has the same weaknesses and strong points as other languages with those characteristics. Personally, I think PHP is strongest in fact without using the class system religiously, and instead making major use of its array/list type and functional code patterns.

Which brings us to 5 and 6. PHP's unique strength and primary reason for me using it is its execution model in a web server environment. Every other language and web framework has gone the way of the application server, but PHP is using a per-request execution model which is incredibly powerful if used right. Per-request execution sounds like a high-overhead situation, and in the past it was, but while there is undoubtedly some cost associated with it, the FPM engine is really quite efficient with it.

In exchange for this you get to benefit from a stateless app. If your code, the interpreter, or a library screws up, you're not taking down the server with it, you just disrupt the requests that actually hit the bug. You can tailor your app's code paths with this execution model in mind, loading and initializing only what you need. Since the environment is torn down after a request finishes, there are no leaks or complex GC gotchas. Scaling up becomes easy, because state is not stored in your code. You can spin up as many servers as you like, distribute requests among them, and they don't have to be aware of each other. Retracing what happens per request becomes very easy, which is great for optimizations and debugging. And you get live code reloading for free. I love this, it's so simple and elegant.

Of course, there are lots of things this is unsuitable for, especially when you really do need a persistent app server. But even in these cases, it can be advantageous to write a small broker-style server in C or Node (or Go, or Erlang, whatever you want), and put the intelligence part in a PHP backend API. I use this setup in some projects where Websockets or other persistent protocols need to run: the broker needs to be updated very infrequently, so it can have a gigantic uptime, and the backend PHP API gets updated all the time transparently with a git pull - nothing needs to be restarted, everything just works.