Think of Alice calling a function that will read a specified file. One way to do that is
readfn("/u/alice/data.txt")
The problem is that readfn() needs permission to read any file that Alice has permission to read. A better approach is for Alice to do
handle = open("/u/alice/data.txt", r)
readfn(handle)
Now readfn() doesn't need any of Alice's permissions because "handle" is a capability.
Now consider a DWN capability that specifies a collection, analogous to "/u/alice/*"; call it cap1. It makes perfect sense for Alice to hold such a capability. One way for Alice to do an invocation is
readfn(cap1, "data.txt")
There are two problems. The first is a violation of Least Privilege. Invoking in this way means Alice is giving readfn() permission to read everything in "/u/alice".
The correct approach is for Alice to do
cap2 = delegate(cap1, "data.txt")
readfn(cap2)
Note the way the capability is used as the argument to the function.
The second problem is that you've separated designation of the specific object, data.txt, from the authorization to use it, cap1. In more complex scenarios that can lead to a confused deputy vulnerability. Although it was stated in the call that DWN has no APIs that involve more than one argument, @andorsk asks about calls involving multiple arguments. In that situation Alice would do
cap2 = delegate(cap1, r, "input.txt")
cap3 = delegate(cap1, w, "output.txt")
copypaste(cap2, cap3)
She could also invoke an operation on a collection, e.g.,
cap2 = delegate(cap1, r, "/u/alice")
cap3 = delegate(cap1, w, "/u/alice/backup)
backup(cap2, cap3)
In this case the operation is being performed on the collection, so it makes sense to designate the collection. The point is that the capability designates what is to be operated on, not some other piece of information.