The advantage of php arrays (imho) is that you can treat them as associative arrays or not dependening on the situation. The lookup behavior is the same for both though, which is convenient.
i don't know python or ruby enough to compare, but it is nicer than javascript where associative arrays (ie objects) and real arrays are entirely different types.
But no other language I've used would work this way. hash[8] would be the same as hash[010] and hash[0x8], and distinct from hash['8']. In addition, if anybody told you that strings would be interpreted as integers, you'd expect that octal strings (which PHP obviously understands) would be interpreted as integers as well! Instead, only decimal formats are handled.
This pernicious confusion of datatypes in the name of convenience is exactly what makes writing correct PHP code so infuriating.
If you want to put the blame entirely on "bad PHP developers", I have some datetime and object-equality behaviors to discuss.
A claw hammer that occasionally bites your hand off is a bad claw hammer. (Bad! No biscuit!)
Its not proof the language is bad, its proof the poster is no better than the truly bad programmers who use the language he is trying to make fun of.
$bool = (08 === 0);
var_dump($bool);
bool(true)
With a language like that, I think it's safe to blame the tool.
Actually, while we're on the topic: these should be separate types, for exactly the reasons I outlined in that code snippet. Arrays and hashes have entirely different memory characteristics, access times, growth strategies, and indexing semantics! Trying to smush both models into the same construct is what leads to PHP's befucked implementation of "arrays"/"hashes", which succeed at being neither.
As an example, compare Ruby (an abysmally slow language) to PHP on array iteration--a task in which PHP loses by a huge margin on both memory and time complexity.