/usr/bin belongs to the package manager for your distro. Don't put anything there.
/usr/sbin is the same but house executables that should only be run by root.
/bin and /sbin are analogous but house the minimal set that needs to be present during early boot in case /usr is on a separate partition. In practice, distros have largely moved to making at least /bin and /sbin symlinks to /usr/bin and /usr/sbin, with some making everything else a symlink to /usr/bin.
/usr/libexec holds executables installed by the package manager but meant to be run only by other programs, not by interactive users.
/usr/local/bin and /usr/local/sbin hold executables installed manually rather than by the package manager. By convention, the package manager should never touch this and it will be left alone during system upgrades. In theory, it holds executables meant to be used by every user of a system, but if this is a desktop system with only one user, putting your personal stuff there is harmless.
Not part of the FHS, but according to cross-desktop group standards, ~/.local/bin is where you put executables meant to be used by a single user only. The package manager won't touch this directory, but third-party installers like pip and what not should theoretically be using it (not ~/.cargo/bin like cargo does).
/opt effectively serves a similar purpose to /usr/local, but for software that expects all of its dependencies to be hermetically contained within a single top-level directory rather than shared. This is often because /opt is mounted via NFS and shared across multiple hosts that might not all have the same common system-wide dependencies. I can't think of a whole lot of examples where this is still commonly used, except that Kubernetes puts the CNI plugins here.
Also, technically if you're booting via UEFI, then your bootloader or any other EFI executables should be at the root of your EFI system partition, which in Linux will usually be mounted at either /boot or /boot/efi depending on the distro, but users should rarely be messing with this unless you're doing Linux from Scratch or really know what you're doing. This also includes Linux itself in a Linux distro because the kernel is an EFI executable now thanks to EFISTUB and you don't actually need a separate bootloader if you really know what you're doing.
/usr/bin belongs to the package manager for your distro. Don't put anything there.
/usr/sbin is the same but house executables that should only be run by root.
/bin and /sbin are analogous but house the minimal set that needs to be present during early boot in case /usr is on a separate partition. In practice, distros have largely moved to making at least /bin and /sbin symlinks to /usr/bin and /usr/sbin, with some making everything else a symlink to /usr/bin.
/usr/libexec holds executables installed by the package manager but meant to be run only by other programs, not by interactive users.
/usr/local/bin and /usr/local/sbin hold executables installed manually rather than by the package manager. By convention, the package manager should never touch this and it will be left alone during system upgrades. In theory, it holds executables meant to be used by every user of a system, but if this is a desktop system with only one user, putting your personal stuff there is harmless.
Not part of the FHS, but according to cross-desktop group standards, ~/.local/bin is where you put executables meant to be used by a single user only. The package manager won't touch this directory, but third-party installers like pip and what not should theoretically be using it (not ~/.cargo/bin like cargo does).
/opt effectively serves a similar purpose to /usr/local, but for software that expects all of its dependencies to be hermetically contained within a single top-level directory rather than shared. This is often because /opt is mounted via NFS and shared across multiple hosts that might not all have the same common system-wide dependencies. I can't think of a whole lot of examples where this is still commonly used, except that Kubernetes puts the CNI plugins here.
Also, technically if you're booting via UEFI, then your bootloader or any other EFI executables should be at the root of your EFI system partition, which in Linux will usually be mounted at either /boot or /boot/efi depending on the distro, but users should rarely be messing with this unless you're doing Linux from Scratch or really know what you're doing. This also includes Linux itself in a Linux distro because the kernel is an EFI executable now thanks to EFISTUB and you don't actually need a separate bootloader if you really know what you're doing.