Moreover, the handling of thrown exceptions is far more scaleable if something like Exception::Class is used in favour of parsing fatal error strings - the likeliehood of breaking client code is far greater when the client code parses the error string than when the client code attempts to catch a known class of exception i.e. the interface is greatly simplified, which as outcomes go, is highly desirable.

To my mind, the use of Error solely for the, slightly distasteful, syntactic sugar is a moot point : the intending user has to compare (for themselves) the benefit of tidier code with the drawback of a non-returning return in the try/catch blocks (as by perrin et al in this thread) - a well understood drawback that can be mitigated for by the simple expedient of a specific case (pun intended) in the coding standards coupled with code review and good unit test cases. The memory leakage problem, as noted in the above link, appears to have now been fixed.