Why running named(bind) in chroot is so important for security? Or maybe it is not?

As @Some Guy mentioned you have to think about this in historical perspective.

The historical perspective was that a single piece of hardware was a dozen or so of different services under a single operating system. If one service was compromised then everything on that hardware was compromised.

With virtualization this is far less of an issue. While it is not impossible to escape out of a VM it is far from trivial. It is certainly more difficult to break out of a VM then it is for a process running with root privileges to break out of a chroot. So my bind servers are running on their own VM. There really isn't much point for a chroot in that case since damage is already limited simply by the fact that it is a VM.

A chroot is a very weak attempt at creating something like a VM. Chroots can be escaped from though by any process with root privileges. A chroot is not intended and does not work as a security mechanism. A chroot with a BSD jail, or LXC gives you OS level virtualization and does provided security features. But these days with it being so easy to spin up a new VM of an entire machine it might not be worth the effort to setup, or learn how to use the OS level virtualization tools for this purpose.

Earlier versions of bind didn't drop privileges. On Unix, only the root account can open ports below 1024, and Bind as we all know needs to listen on udp/53, and tcp/53. Since Bind starts as root, and doesn't drop privileges any compromise would mean the entire system could be compromised. Almost any software these days will start open their sockets and do any other stuff that requires root privileges then they will change the user they are running as to a non-privileged account. Once the privileges are dropped the impact of being compromised is a lot lower to the host system.

The other answers are pretty good but fail to mention the concept of security in layers. Every layer of security you add to your system is another layer that an adversary must overcome. Putting BIND in a chroot adds one more obstacle.

Say there is an exploitable vulnerability in BIND and someone is able to execute arbitrary code. If they're in a chroot, they need to break out of that before getting to anything else in the system. As mentioned root privileges are required for chroot-breaking. BIND doesn't run as root, and there are supposed to be minimal tools available in the chroot, further limiting options and essentially leaving only system calls. If there's no system call to escalate privileges then the adversary is stuck looking at your DNS records.

The aforementioned situation is somewhat unlikely as SomeGuy mentions, BIND has quite few vulnerabilities these days and they're mostly restricted to DoS type scenarios rather than remote execution. That said, running in a chroot is the default configuration on quite a few OSes, so it's unlikely to take any effort on your part to keep the ever-so-slightly increased security.