No, I think we're using the same definition. I'm just pointing out that the developer of "it" may not be the user of "it" especially as it pertains to APIs.
I understand YAGNI's usefulness for in-house software, or internal functions inside software that will escape to users' machines. Only write what you need, when you need it.
The problem is that if Tim Bunce never needed selectall_hashref, who would write it? Would each user of the DBI that needed it then write it, and we would end up with about two dozen different selectall_hashref's, with a half-dozen different sets of parameters, some of which only work with Oracle, some only with MySQL, some with DB2, ...? Or, if Tim sees the usefulness of this function (to others, in the future), he can easily put it into the official DBI, and save hundreds of developers hours of time each?
Similarly in my own code - we put in a bunch of functionality that we won't use. But it allows our customers to plug in (using Java, C, perl, or even shell) and do things. We can't be sure that all of the functionality that we build in will be useful. In fact, I'm pretty sure that some of it is useless. Just that I'm not entirely sure which parts that is ;-) So we build it all, and hope they come. Er, we build it all and let each user decide which part(s), if any, they need. Maybe we'll use it, too, in the next version. But for now, we don't. Yet, as a public API which we think is large enough for everyone to do what they need to do, we have to build it now, even if parts of it will never be needed. If we waited to find out if someone needed a particular piece of function before writing it, well, our next release is slated for a year from the release of the current version. And, no, this cannot be fixed in between.