Yes: compatibility reasons which affect security.
This restriction was deliberately not removed, for a reason reported faithfully by LWN.net. Removing the restriction would create a security hole in some versions of
fusermount had been improved earlier by adding
UMOUNT_NOFOLLOW, and this made it safe. However the old versions of
fusermount were still widespread enough to be a concern.
See Mount point removal and renaming, LWN.net 2016.
As far as I can tell from the linked thread, patches 1-3 would have allowed moving a mount point. And then patch 4 was added to forbid it :-).
This is not complete proof. However it suggests the restriction in patch 4 was not due to internal implementation reasons. I also believe kernel developers would have mentioned, if they had any idea that user expectations would have been broken by allowing mount points to be moved.
@schily, however, points out there is something strange about allowing mount points to be moved (or unlinked). It appears that it was possible to allow
rename() of a mount point. But only because it was interpreted as renaming the file underlying the mounted filesystem(s).
It would be a strange exception to the current rule, that
rename(oldpath, newpath) requires that the oldpath and newpath are on the same filesystem. Otherwise it fails with EXDEV. (In fact they must be on the same mount of the filesystem).
I thought of one extra little strangeness under Linux. If you set the Linux "immutable bit" on the underlying file, I think the rename() should be denied. But if you inspect the immutable bit on the mount point, you will not see the immutable bit of the underlying file! I expect it works fine, it would just be rather annoying if you ever had to troubleshoot it.