chroot only makes sense for applications which can commit to exclusively operating out of a single directory, ever. (It also requires the process to have superuser privileges, so it can't be used by applications which are run as users.)
os.Root() is more about putting a "seatbelt" on filesystem operations - like restricting operations related to an application's cache to its cache directory, or restricting a file server to serving files from the appropriate shared directory. It's not the same kind of ironclad guarantee as chroot, but it'll still protect an application from simple directory traversals.
After this dance, you can call chroot from within the new namespace. It's often also possible to use unprivileged bind-mount /dev, /sys, /proc, for a more regular execution environment (although some container runtimes block this unfortunately).
Yeah, I like your examples. In such scenarios, it makes sense when we're just trying to protect against our own bugs rather than a user deliberately sending a path that leads to the password.txt file.
os.Root() is more about putting a "seatbelt" on filesystem operations - like restricting operations related to an application's cache to its cache directory, or restricting a file server to serving files from the appropriate shared directory. It's not the same kind of ironclad guarantee as chroot, but it'll still protect an application from simple directory traversals.