Comment 15 for bug 1227520

My main problem with symlinks are that we wouldn't be able to access the original file as the .tar.xz would contain a symlink instead of the file it's diverting.
Symlinks also come with the problem that some tests may fail (the symlink is typically seen as a file but may also be a directory) and some tools won't recurse through symlinks in the same way they do through directories.

On top of that, outside of the very small performance gain we'd gain, they really wouldn't solve much, this bug highlights two problematic cases:
 - Atomic file modification (by creating another file, then doing the rename+delete) which isn't possible as the directory itself is read-only. This would be no different with symlinks.
 - Symlink target changes. This actually works with bind-mounts, if you change the target of the target file but doesn't with symlinks as it'll instead try to change the original file which is read-only (unless we go through a separate read-write directory and add an extra step as was discussed in this bug).

So all in all, I saw symlinks as adding a lot of complexity (copying any file/directory they replace in some other location of the rootfs, ...) for only a barely measurable performance gain (and arguably a cleaner /proc/mounts, if anyone cares).