'relative to file location' is old school pd style, easy to understand and together with the concept of inheritance, it covers every use case i can think of (which implies that i would try to adapt the way i code to pd and not vice versa).
I'd almost agree with you as long as inheritance were a strong part of the model.
But...
Say I'm teaching a computer music course, and I've created a big library of commented and documented abstractions to do all kinds of neat things. I've written a script to copy the files from some global location to the user's current directory, all of them put into a directory called ./cm101-abs/ This directory is further subdivided by abstraction function: cm101-abs/control/ cm101-abs/noise/ cm101-abs/math/ etc. In order to use them the students need to either alter their search path or put in a rather lengthy [declare] which might be beyond the scope of the first semester, or as part of the script I can give them a blank file with just the [declare] statement, which they can edit as they like.
But, if Pd had a simple flag which allowed an abstraction instance to export a [declare] path to its parent, using names relative to the parent, then I can make an abstraction with just the [declare] from above, but instead of -path I use some other flag. Then all the students have to do is include an instance of that abstraction in their patches and they have access to the larger suite of abstractions. I think of this roughly as something like including a header (providing access to the interface of objects defined elsewhere). This is much simpler for the students and the teacher, and as a bonus the students learn something similar to the "include" concept.
Now, let's say I have a fairly complex dynamically patched impulse-response convolution patch called [IRconv~] using [rfft~]'s all over the place, and it has a specialized abstraction called [fft-conv~] that's loaded dynamically into the patch which has arguments specifying the $0 of the parent abstraction, the block size, its associated delay (minus block delay), the name of a [table] in the abstraction to which is written a specified set of samples from the impulse response, the name of a [send~] to [receive~] the incoming sound from, and the name of a [catch~] to [throw~] to. Such a "helper" abstraction is useless in any other context, so I want to keep my students from using it on its own, because it might even be detrimental and confusing to try. I can tell them "don't use this." Or I can stick it in a subdirectory of the directory containing [IRconv~].pd, which is not now included in the main patch's path -- so then ideally I [declare] that path in [IRconv~] relative to [IRconv~].pd, and it should work without passing this path to the space of [IRconv~]'s parent -- this is what you advocate if I understand correctly. But, this doesn't keep a smart student from declaring the same path in the toplevel... so then I counter by changing the [declare]ation of the path to [fft-conv~] in [IRconv~] from public to private, and then it throws an error when she tries to declare that path in the parent and load [IRconv~] at the same time.
Both things can be worked around, but I think the former would be especially useful. The public/private thing isn't essential, but I think it's pedagogically more sound than not having the option. You might also want to allow abstractions not to accept their pathy inheritance, especially for resources.
Matt