> It is the worst in nearly every category you cite.
If you think that, you don't have much real world experience.
> Are there automated deployment tools written in PHP for PHP applications? I mean ones that can be taken seriously.
Why do you need a deployment tool written in PHP for PHP applications? Are you serious? It's a ridiculous proposition to care that much about the language the deployment system is written in. What I care about is what benefits it brings me.
Where I am now we have our own deployment system, btw. - we operate a private multi-tenant cloud specifically tuned to the type of workloads our customers have, at a cost ~1/3 of what it'd cost us to host our current infrastructure somewhere like EC2 with equivalent redundancy and performance. That is including the development and maintenance costs for our in-house tools. As part of that we have a rapidly improving set of deployment tools. Handling deployment of PHP was pretty much the simplest part of that system.
> What optimization options do you have for PHP? What latitude do you have with hosting?
Are you for real? I love Ruby. I'm working on a Ruby compiler as a hobby. But scaling PHP is trivial compared to RoR. I don't need optimization options for PHP - one of our clients processes restaurant bookings worth 50 million pounds a year via a setup that consumes ~30% of CPU resources on two frontend servers with a combined leasing cost of ~1000 GBP/year. The vast majority of their cost (their total yearly cost for their internet presence is about 3 orders of magnitude above the cost of the servers hosting the PHP code) for this system is marketing, support, power and bandwidth in that order. Cost of the frontends that PHP run on comes at the very bottom - it's a rounding error. If we needed more frontend capacity? We'd add another couple servers like that, and it's still be <1% of their cost.
What costs us money on the hardware side is database servers and network infrastructure. Web frontends for typical simple web apps are cheap. Sure, there are exceptions (but as much as I love Ruby, RoR is certainly not going to save you scalability grief in the cases where scaling PHP becomes hard or costly).
> If you're not Facebook, writing your own PHP engine, you're going to be stuck with one of a few that are generally crappy.
If you're not Facebook, there's no compelling reason to write your PHP engine as PHP is fast enough for pretty much anything you throw at it until you're in a situation where you have thousands of servers, where shaving a few percent off here and there starts creating large savings.
A vanishingly small number of companies ever reach that scale - optimising for that in advance is lunacy, and most "cleaner" languages does not provide a better starting point in that respect. Ruby, for example, is far more costly to scale.
> Cost and developer time are non-factors since the time you'd need to learn PHP is probably higher than other languages that make more sense and aren't filled with anachronisms you will spend half your time working around.
Spoken as someone who doesn't know the market. I have a steady supply of qualified PHP staff. In fact, we have recruiters hounding us every day with cheap candidates that know PHP. Ruby? Rarely, if ever. Those who know Ruby well enough have an easy time finding better paid jobs.
> You can train someone up in Ruby on Rails in two weeks
Bullshit. You can get a senior developers that is already expensive to relative beginner level in that amount of time. Or you can hire a PHP developer that is already skilled at ~60% of the cost.
I've seen "RoR developers" with two weeks experience, and what they produce is not pretty, and certainly does not result in a good ROI compared to more pragmatic solutions. I'm all for using Ruby if/when you have a good team of Ruby developers, but you then also need to realize that you have an expensive team. It makes sense when your team is highly experienced and rapid turnaround is more important than keeping the cost down, or if your personal satisfaction is more important to you than the cost - both can be perfectly valid reasons. If I were to start a new company now, I'd pick Ruby myself. But I would do it because it is what I would prefer to work with, not out of any illusion it's currently a cheap choice.