Wikipedia talks about the security of chroot, because chroot is often compared to sandbox (which don't provide chroot) or others with the purpose of providing security with isolation.
chroot() (it is a UNIX system call) is the process of changing the the apparent root directory (/) to an another one pointed by the system call.
It means if a chrooted executable to /dir/target want to access to load/lib/ld-linux.so.2(hard-coded path in the executable), the real access will occur to/dir/target/lib/ld-linux.so.2
So it implies that each files and library the program need to access need to have their usual real path (prefixed with/) to the chrooted path (/dir/target in this example). If you use a full system inside a chroot you will finally end-up with the directory structure described in man hier but prefixed (for the chrooted programs) with the chrooted path. It also means you may use different binaries of a different architecture (if your CPU supports several ones; such providing a kind of isolation).
As you can see when you look at chroot, the primary purpose doesn't look to provide security, and it is used for other purposes switching from the initramfs root in Linux to the mounted root on the disk (except there's the process mount -o move).
However, as stated by the Wikipedia article, certain implementations such as FreeBSD choose to provide a certain level of security : like disabling the possibility to make a secound chroot inside a chroot. Wikipedia is wrong when it tell chroot need to be run as root. Most systems today have more fine-grained mechanism than user/group permissions.
Jails are designed for providing isolation directly, it allows one to limit the amount of RAM and CPU a process may use; disabling shared memory; restrict permissions...
Some implementations (like with the sandbox command) don't provide chroot. Jails have applications in Operating system–level virtualization, or avoiding damages to the remaining of the system when testing special code.
If you take the example of the sandbox command, you'll see it can't use an alternate root directory structure by itself.
http://www.raspberrypi.org/forums/viewtopic.php?f=31&t=8478 is mentioning qemu-user which is clearly to test programs without having to put them on the Rasberry Pi. This is different than virtual-machines, because no hardware is virtualized here : The binary instructions of the program are converted into native ones which mean system-calls are handled as if the program was run natively.
Here's come the need to use a different root directory structure : some shared object files path names are common over all distributions and architecture (like/lib/ld-linux.so.2). You can't mix several architecture into the same binary. If you replace a shared library by its ARM equivalent, then the files won't be usable for native executables. qemu-user or the whole target system need to be compiled statically for the same reason.
I really suggest you install and set up binfmt. It will enable you to run programs as if they had the same architecture of your machine by launching the qemu-arm-static command automatically...
Then you may want to compile software without cross-compiling, by simply installing a native ARM compiler inside your chroot.
