This is not a functionality issue but a language issue.

It's not a language or a functionality issue. It's a development team issue. In any project it will be best to pick a common error handling mechanism. This is true no matter what language you choose.

If you have multiple people on a team using different coding styles that's a team problem, not a language problem.

Beyond that it's not really an issue. It's trivial to wrap code that handles errors via return values so that it throws exceptions (e.g. Fatal). It's trivial to wrap code that throws exceptions to return errors (via eval {}).

Personally I would recommend using exceptions since I find they have many advantages. However, this is an issue for your development team to decide after weighing the pros and cons.

Exceptions are also completely separate from OO. You can, if you wish, have an exception handling system with just plain strings (although I wouldn't recommend it).

The try/catch syntax supplied by Error has some problems as perrin has already pointed out. However this has to do with prototyping/blocks/closures rather than exception handling in Perl. All the other modules do is provide some syntactic sugar for declaring exception classes and throwing exception objects.

There is nothing special about these classes and objects - they're just normal Perl objects. Exception handling is a core part of Perl and you shouldn't worry about using it if it's appropriate for your project. For many kinds of Perl applications (e.g. DBI) exceptions are really the only way to go.

If I write tests in a project and other people don't, it marginalizes their and my effectiveness. If you're working with other people on a project, you should have coding standards. This is not a language issue, it's a playing-nicely-with-other-people issue.

That's a good way to look at it. There could be coding standards if it's a within company project, not when we're taking over a project from someone else. try-catch block like that isn't a most common coding style in Perl.