I've actually adopted the reverse. It's not a question of when to use named arguments, it's a matter of when not to. That is: assume that all subs take named arguments, and you really have to convince me if a particular subroutine should have positional arguments.
When you're managing a very large project that is constantly growing and changing, it's frankly the only way. Where I work we've actually got a whole slew of code conventions that center around making code future-change friendly, and this is the center-piece of them. Among the others are: giving all key-value pairs their own line, giving all array values their own line, and always putting (unnecessary) trailing commas on list and hash declarations. The point being: diffs and merges only affect the lines that actually changed semantically, and highlite what the actual change is.
Not an editor command: Wq