Obviously, the intent of this feature was to allow a single string to be conveniently constructed from multiple arguments, as the perldoc -f die output demonstrates.   But it is also possible to pass an object.   Quoting again from the perldoc:

You can also call "die" with a reference argument, and if this is trapped within an "eval", $@ contains that reference.   This permits more elaborate exception handling using objects that maintain arbitrary state about the exception.   Such a scheme is sometimes preferable to matching particular string values of $@ with regular expressions. [...]

Packages such as Exception::Class, among many others, make good use of this feature.   I find it particularly useful to be able to catch an exception, and then by use of isa() and so-forth to easily obtain contextual information about exactly what went wrong, in addition to what else I may learn from querying that object’s properties and methods.   (This is also an excellent way to allow inner exception-handlers to determine whether the exception they have caught is one [of a class ...] that they should handle, or one that they should re-throw.)

Sometimes, “throwing an exception (object ...)” is a great way to “bail out” of perfectly ordinary situations.   The Python language, of course, takes this idea rather to an extreme . . .

When invoking code that might throw a string-based exception, I will catch that exception in nearby containing-code, and then construct an object containing (among other things) the caught string, and re-throw that object, so that, throughout my entire application, every exception that makes its way up to outer-level andlers can be counted-on to be an object of some kind.   (Although even these handlers must of course be also prepared to catch a string, which of course would be recognized to be an “entirely unanticipated, out-of-the-blue” error condition, because it should have been caught and object-ified, but it wasn’t.)