But for most general purpose subroutines and method calls, the need for named parameters--ie. calls that take so many arguments that naming them is beneficial beyond an aid memoire for the casual tourist to the code--is strongly indicative of something seriously wrong in the design of the API.

I respectfully disagree.

Named parameters means I don't have to pass a string of undefs because one particular call doesn't use those parameters. APIs using positional parameters have a way of requiring difficult upgrade path.

It's also self-documenting -- instead of a list of variables, each variable is named, which can only help the future software forensic expert.

Many years ago, I wrote a User Interface program in C, and one of the things that I used was lots of parameter passing, knowing enough that global variables were not the answer. Eventually, I had a couple of routines that required a dozen or so parameters, and as the code matured into a lovely congealed mass of spaghetti, I began to dread getting in there to fiddle with calls to that code, precisely because I had to add 'just one more' parameter at the end.

The alternative could have been to pass in a pointer to a struct, which is more or less a hashref, but I wasn't secure enough in my abilities to do that. Too bad, because it would have been the right thing to do, just as using a hashref is the right thing to do.