preamble
i keep hearing people reiterate misconceptions from all over the internet.. thus, i will try to give some clarification
first off; how many accidental discoveries have there been, which simply.. due to cause and effect, ended up being used for something other than its intended purpose?
what was, and what is, a Chroot jail
Chroot was initially designed to change the root directory for the process or user (great for compiling software from unknown sources). this provided security to the base system, as well as a quick test bed appliance, including easy clean-up. years have went by since, and it's concept and implied uses have certainly changed, likewise.
chroot has been used effectively, and is directly in the code base for several programs and libraries (i.e. openSSHd, apache2 + mod_security2/mod_chroot, dovecot, sendmail, openVPN, pam_chroot, and so much more). assuming that all these mainstream applications have implemented faulty security solutions is just not true
chroot is a solution to file system virtualization: nothing less, nothing more. the assumption that you can easily break out of a chroot is also not true... as long as you adhere to the guidelines of running processes inside of the chroot jail.
some steps to secure your chroot jail
i.e. do NOT run processes as ROOT. this could open up a root escalation vector (which is also true inside or outside the chroot). do not run a process inside the chroot, using the same user as another process outside the chroot. separate each process and user into his own Chroot in order to limit attack surfaces, and provide privacy. only mount necessary files, libraries, and devices. lastly, chroot is NOT a replacement for base system security. secure the system in its entirety.
another important note: a lot of people think that OpenVZ is Broken, or that it's not equal in comparison to full system virtualisation. they make this assumption because it is essentially a Chroot, with a process table that has be sterilized. with security measures in place on hardware and devices. most of which you can implement in a chroot.
not every admin has the level of knowledge needed to secure all the necessary kernel parameters on a dedicated server or under full system virtualization. this means that deploying OpenVZ means that your customers will have much less attack surface to try and cover and secure before deploying their applications. a good host will do a good job securing these parameters, and it in turn, this is better for not only everybody on the Node, or in the data-center, but for the internet as a whole...
as stated, the chroot provides file system virtualization. you must ensure that there are no setuid executables', insecure applications, libraries, dangling ownerless symlinks, etc. if the attacker COULD compromise bind, they would need to scour the virtual file system for something to buffer overrun, play with file descriptors, or in some other way compromise something residing inside the chroot- escaping the jail usually through privilege escalation or injecting his or her payload into the base system.
if this happens, its usually the result of a bad update, zero day exploit, or idiomatic human error.
why chroot is still used, as opposed to full system virtualization
consider this scenario: you are running a Virtual Private Server, with the host node running OpenVZ. you simply can not run anything that works on the kernel level. this also means you can not use operating system virtualization to separate processes, and provide additional security. thus, you MUST use chroot for this purpose.
moreover, chroot is sustainable on any system, regardless of resources available. simply put, it has the very least overhead of any virtualization type. this means it is still important on many low end boxes.
consider another scenario: you have apache running inside a virtualized environment. you want to separate each user. providing a virtualized file system through a chroot add on to apache (mod_chroot, mod_security, etc) would be the best option to ensure utmost privacy between end users. this also helps prevent intel gathering, and offers yet another layer of security.
simply put, it is important to implement security in layers. Chroot potentially being one of them. not everybody and every system has the luxury of having access to the Kernel, therefore, chroot STILL serves a purpose. there are a variety of applications in which full system virtuaisation is essentially overkill.
In response to your question
i dont particularly use CentOS, but i know that Bind now drops its privileges before operations. i would assume, however, that bind is chrooted due to its history of attack vectors and potential vulnerabilities.
also... it makes more sense to automatically chroot this application, than not, because not EVERYONE has access to full system/operating system level virtualization. this in turn, and in theory, helps provide security to the CentOS user base:
operating system providers simply do not go around assuming every one is running the same system. this way, they can help provide an additional layer of security at large...
there is a reason why so many applications use this, and why obviously your OS does by default: because it IS used as a security feature, and it DOES work. with careful preparation, as previously stated, it is yet another hurdle the potential attacker must overcome- most of the time, restricting damage to done to only the chroot jail.