That premise is a specific case of the more general premise: directories not specifically allocated to users are directories for system-wide use, and unprivileged users should not be able to add, modify, or delete files in system-wide directories. This is why we don't allow unprivileged users to create files in
/usr/bin, or under
/usr/local. With limited exceptions, standard practice is that there are no directories which are writable by multiple users, and which allow users to modify each others' files.
/tmp is world-writable, but the sticky bit protects against users replacing each others' files. Often,
/tmp will also be mounted
noexec, which further reduces a user's ability to disrupt other users. Every other exception I am aware of is reserved to specific applications that have their own locking rules, and generally store only files that can be lost without serious consequence (such as a High Scores table for a game).
On a typical install,
/opt/bin is part of the $PATH for all users, including root. It would be a security problem if an unprivileged user could add executable programs that other users would find via $PATH, because then users other than the creator might unintentionally run such a file. It is the responsibility of the root user to prevent this problem by not creating any directories that are both writable to users and treated as "system-wide" by common conventions. (Arguably, a system where root has specifically arranged that
/opt is not in the standard $PATH would then be safe to allow users to write to
/opt. Personally, I would push users somewhere else, because even if
/opt is not in $PATH, it is still a well-known name that, by convention, is only writable to root, so some users or programs might still assume the latter and do something unsafe, even if it isn't in $PATH.)
On my system, the LLVM bin directory is lower in $PATH than
/opt/bin, so someone with write access to
/opt/bin could create a file, such as
/opt/bin/llvm-cxxfilt, that would be run in preference to the real LLVM's
llvm-cxxfilt. Then, when next I run a bare
llvm-cxxfilt < something, I run their version in
/opt/bin instead of the version I expected to be found at
/usr/lib/llvm/version/bin/llvm-cxxfilt. This will at the very least be surprising, if they
exec the real one with different options. It could be a security problem if their program also uses its authority as me to compromise my account, by uploading gpg or ssh keys, by modifying my dotfiles to run something malicious later, etc.
Gentoo packages of prebuilt binaries, such as firefox-bin or rust-bin, typically install under
/opt, so when I saw that you had Tor Browser there, my expectation was that you had used an overlay that installed the files there. Such an overlay should not have made them writable to your user. Based on your latest post, you didn't use an overlay; you used a root shell to
mv those files there. If you had put them somewhere else, I would have more readily recognized that this was not a package manager controlled install. If you had changed their ownership to
root when you moved them, then the browser wouldn't be rewriting its desktop file, your post would not have needed to warn about the rewrite, and I would've assumed the files were safe. Referring to
/opt as "default installation path" also sounds to me like a scripted install picked that directory for you.
