Depends entirely on your metric. It's far too easy to introduce subtle bugs, especially security oriented ones, in PHP. If I had a dollar for every XSS, remote file inclusion, CSRF, arbitrary file read, etc vulnerability I found in a "good" PHP app, I'd be a very wealthy man. Some things are mitigated by using a good framework, but in most cases people get them horribly, horribly wrong.
While testing apps, PHP immediately throws up red flags -- it's simply not likely to be done right. It can be, but it's very rare.
One very illustrative example: arbitrary code execution. I've lost count of the number of arbitrary code execution vulnerabilities I've found in PHP applications. In contrast, I recall very vividly the last arbitrary code execution vulnerability I found in a Python application: I uploaded a PHP script to the server, which was also running mod_php. ;-)
The problem here is simple: most web servers that run PHP are configured with a rule that says "If a file ends in .php, execute it as PHP." This is useful for new users: it allows them to run and execute separate PHP scripts very easily. But it's also a potential security vulnerability if an attacker can upload a PHP file to your server.
If you're using a framework, you typically have a fixed number of scripts that should be executable and you can configure your web server appropriately. However, that requires a VPS or dedicated server.
Edit: If you're interested in an actual language-level difference between PHP and Ruby/Python that affects security, PHP scripts accepted null bytes as part of filesystem paths until recently (PHP 5.3.4, which added protection against it, was released at the end of 2010).
Rails is a DSL based on Ruby to build web applications that has hooks into a rich library that helps with that. PHP is a language designed to build web applications (although it can be abused to write any type of application)
Thus, in your career you tend see more PHP apps that were badly-implemented.
But by now I am mature enough to understand that if you hire bad programmers you get bad code irrespective of the language its written in. You can use any tool you want, if you use it badly the result is going to be bad. These are days of Python and Ruby fanboyism so very obviously everything is going to look ugly in front of it. Code bases in other languages will be declared legacy and the same thing will be translated to the new shiny language and called the 'modernized' code bases. Your RDBMS use cases will be shoe horned to NoSQL databases and declared designed for the web. This will go on and on for anther few years...
Until we get to see page long blog posts another few years from now describing how many bad Python + Django examples can be found on the net. Or how bad Python and Ruby Legacy codebases are. How framework dependency with Django, Rails or Twisted sucks. Or how someone had to spend huge engineering effort migrating from Python 2 series to 3 series. Or how they had to rewrite a large part of SQL logic to work with NoSQL databases.
This trend repeats every few years, every few years a set of tools get trolled badly.
Now which languages make it easier to write more good code? Everyone talks about the lack of good PHP code and the response is "well there's plenty of bad python code out there!". What we will never see are any examples of PHP code held up as being great a few years from now.
Yes, every few years a set of tools get trolled badly. The same tools that were considered sub par by professionals at the time.