I think that the most common use of chroot (not necessarily the only, but most common) is to define a 'false root directory' to contain a process and its accesses to data, so that the process is not allowed to do certain things.
So, imagine an example where some program is accessible to untrusted users and that it is possible that the untrusted user can somehow use the program (or, potentially, something like a shell spawned from the program) to look around the filesystem and maybe even replace files. This is undesirable, because they'll be either seeing data that no one intended to see, or changing files that no one intended them to change and that could have all sorts of implications.
Now you might point out that if you don't want people to have that kind of ability there should be some mechanism in the program that prevents it. The trouble with that argument is that, over the years, many programs have had problems in which someone has figured out some 'corner case' (or bug) in which this strict encapsulation isn't as strict as it should be.
So, how does the the 'false root' system help here? Well, if you have a false root and all the sensitive files are not under the false root, that is an impediment to the evildoer getting at them. Now, it does take some care and it might not be the most secure system (there may be some chance of breaking out of the chroot 'jail' and getting to the main filesystem), but it is another obstacle in the way.
These days, a proper virtual machine might be a more thorough approach (but might have an unacceptable overhead in many circumstances) or a lightweight VM.