The downside of that is that you don't get the automatic "bad feeling" when you put in a hack. It just doesn't stand out like a sore thumb (like it would in Ruby), so it's very easy to ignore the hack. Since PHP is an extremely hack-friendly language, where it is very easy to take damaging shortcuts, and it lacks the feedback mechanism to make you aware of when you've taken a bad shortcut, every large PHP project seems to eventually end up the same: a monstrous pile of hacks, one uglier than the other.
I don't have that problem with Ruby at all, for the record. Ruby is very hack-friendly too (even more so than PHP), but because of its natural elegance, whenever you do something plain bad it is immediately visible and remains so until you clean after yourself.
I could talk about all the cruft in the global namespace, the lack of consistency in the API, the appalling OO implementation, the lack of a super-successful framework like Rails... but ultimately, what bothers me is the result of all those problems: ugly code that keeps getting uglier.
Why did ugly code bother me with my first start-up? Because it is hard to care for ugly code. Once your beautiful start-up's code turns into a pile of spaghetti, you start to wish you were doing something else. And that's a pretty bad place to be when you are the sole maintainer of your start-up's code. It won't stop you from ploughing on - but it will slow you down a lot, and you don't need that when you're a start-up.
I'm very familiar with PHP. I built my first start-up on it, and it was a costly mistake. I know PHP very well and loathe it for many good reasons.
I think the author should try giving up on PHP now. He may well find that the world seems like a better place after that step.