I think it's worth pointing out that while I suspect you may have intended that as pure snark, there is a deeper point lying under it. Assuming this continuous deployment is something like "developer picks up bug, hacks out whatever solution works, deploys it five minutes later", then you are punting on any issue that may require a bit more introspection. This most notably includes security, but there's other things that this procedure will fry too, like longterm maintainability and such. Not to mention offloading QA onto your customers, which may work for a free webservice holding nothing of particular value but hardly works for everybody. (And I hope they have good backups.)

With this logic, it's perfectly fair to point out that WordPress's security record is absolute shit (tptacek: "There are unforced errors in Wordpress. Every web application will have a cross-site scripting mistake. It takes a special one to have "anonymous commenter" -> "admin" privilege escalation, or executable style templates." - http://news.ycombinator.com/item?id=1328583) and it's fair to conclude that this "We systematically and deliberately fail to check our code before deploying it!" approach to development may be a contributing factor.

Now, nothing stops you from implementing "take bug, code solution, run it through code review and QA, deploy" on a patch-by-patch basis, but I have a hard time imagining making 20 releases a day with that procedure, so I'm assuming that's not what they are doing with some reason.

Basically, what I'm saying here is that hearing WordPress advocate this model is a strong argument against it. If they honestly think it's not costing them anything, or even just a net benefit, then I call their judgment into question. Or perhaps rather, further into question, since I think their security track record was already calling their judgment into question.