There is a bit of flexibility in how run-time systems handle denoting the file name. One thing that is often done is give the path as it was specified in the compile command. This could be ./byte-comp.el or ./emacs-lisp/byte-comp.el (And from this you might see where I'm going with this).
One run-time system for a programming language I am familiar with started with the what I described (use path as given in invocation) and then and switched to turning everything into an absolute path. Personally, I like giving both when the starting point was indeed a relative path.
Now as to the portability. Yes, if the file is run on another system, the path isn't exact. But it does give some idea of what we are talking as you git closer to the bottom of the path and that may be helpful.
Consider cases where I have a stable and development branch and then install into say /usr/local/share/emacs/lisp. Even though the top-level directories are not the same, it still is useful to know where in the source code tree (whether on my system or not).
And I recall one Emacs package that concatenated a bunch of bytecode files xx-a.elc
xx-b.elc and called the result xx.elc. Although unusual, with the
filenames in the bytecode, you can unscramble this .
And finally there will be cases where the path is exact.
In sum, just because sometimes it doesn't work out, doesn't mean it will be totally meaningless all the time. And I prefer "sometimes useful" to no information, however accurate that is.