Of your reasons, the second makes some sense. And, of course, the general guidance is that any software installation shouldn't be done in the base OS, but rather in a jail. rclone is somewhat unusual, though, in that it's a standalone binary which can run on its own without any supporting libraries or other software. As a result, there's no real reason not to put it somewhere on your pool and call it with an explicit path--I still tend to think a jail for rclone is unnecessary.
Actually, I just thought of a fourth, and perhaps most important, reason. In a pool I can create a directory, /mnt/Backup, and attach
several external mount points to it. Then a single rclone command,
rclone copy /mnt/Backup ArbitraryRemote:
can back up everything one wants to back up, in one swell foop.
I suppose without jails one could write a script including separate rclone commands for each external dataset one wants to include. Or, perhaps, do something fancy with symlinks. But it seems to me the mount-point-in-jail solution is easier to implement and maintain (assuming one understands how to deal with permissions -- something I'm still learning; see the
Need help understanding permissions for mount points in jails thread that I just started

).
I remember reading somewhere about components "doing one thing well" leading to good computer system design. ;)