Instead of automatically throwing a 500 on a random, unimportant, uncaught exception, PHP makes a best effort, and most of the time the result is fine.
And how precisely does PHP "know" which exceptions are important and which are not? In my experience of 6 years as a web developer, the faster and the more explicitly something fails the better. If the user gets a 500, that's a pretty clear sign of a problem, I get an email notification about it, including user id, session data etc. Then, in most cases, I can easily see what the problem was, decide what the correct behaviour is and create a fix immediately and even notify the user after releasing it if I wish to do it. If there is no exception there is a case in the code I was not aware of when writing it and it will still not be brought to my attention. In the best case, the user will report some problem with the functionality and I will have to spends hours trying to find the logs for this user and reproduce the problem, which will now be much harder, quite some time could have passed since the error, the database entries for the user could have change meanwhile (including corruption caused by the system continuing to operate despite an error) and so on. In the worst case, the bug will continue to affect users (which might not even know what the intended behaviour was) and I will learn about it a year from now, accidentally.
Reproducing bugs is hard enough in web applications due to their distributed nature, some of the applications I worked on had serious business-affecting bugs that went unnoticed for months and failure to clearly signal errors is one of the common cases. It doesn't matter whether you are in banking or just building another social CMS/CRM "kind of thing", if you have bugs you loose users and with them money.
Catching exceptions and returning a 200 OK blank page is about the worst thing that PHP is doing. A simple error can trash your google index (Oh, page replaced by blank content, fine!) or mess up API communication when the receiver does not explicitly check for the response content (POST to endpoint, 200 OK, ok, nice). And while you can catch and handle some of those errors with your own error handlers, there are error classes that you can not handle and which will always be handled internally. It's a pure mess.
I understand fail fast, and errors do still get logged and made visible (New Relic is great like that). I would rather fail a bit slower, silently, though. It's much less jarring to users, and therefore you lose fewer.
It's less jarring for the users that you have to tell them weeks after they entered some important data that all this data has been lost? Is it less jarring if they order something and the order confirmation does not arrive and they don't know whether to try again or not?
If there's an issue that affects business logic I'd like my app to display "Sorry, something blew up. Please leave a message and we'll get back to you." instead of chugging along quietly. If the error is not critical (some external feed gone, whatever) _I_ as a developer can decide to catch the error and handle, log or even ignore it. But it's not PHP that can decide to do so.
And how precisely does PHP "know" which exceptions are important and which are not? In my experience of 6 years as a web developer, the faster and the more explicitly something fails the better. If the user gets a 500, that's a pretty clear sign of a problem, I get an email notification about it, including user id, session data etc. Then, in most cases, I can easily see what the problem was, decide what the correct behaviour is and create a fix immediately and even notify the user after releasing it if I wish to do it. If there is no exception there is a case in the code I was not aware of when writing it and it will still not be brought to my attention. In the best case, the user will report some problem with the functionality and I will have to spends hours trying to find the logs for this user and reproduce the problem, which will now be much harder, quite some time could have passed since the error, the database entries for the user could have change meanwhile (including corruption caused by the system continuing to operate despite an error) and so on. In the worst case, the bug will continue to affect users (which might not even know what the intended behaviour was) and I will learn about it a year from now, accidentally.
Reproducing bugs is hard enough in web applications due to their distributed nature, some of the applications I worked on had serious business-affecting bugs that went unnoticed for months and failure to clearly signal errors is one of the common cases. It doesn't matter whether you are in banking or just building another social CMS/CRM "kind of thing", if you have bugs you loose users and with them money.
See also: http://en.wikipedia.org/wiki/Fail-fast