The conventional technique of returning error status from the called routine depends on the calling code to manage any error condition and possibly to pass the problem up the calling chain. That process relies on the writer of the calling code to correctly supply error handling code at every point in the calling chain. This of course depends on the programmer being aware that the error handling code needs to be supplied and interested enough to supply it. It also requires that the code context be appropriate for handling the error, which often may not be the case (inside a module for example).

Using exceptions for error handling turns all that around. Code that can't handle errors or doesn't care simply does nothing. If nothing cares, the error gets handled by escaping all the way out to the $SIG{DIE} handler. At that point the programmer may start to care enough to take notice and do something about error handling. ;)

Oh, and none of this is really any different for OO or procedural styles of programming.