The programs become provably stable and deterministic. Furthermore, the determinism can scale. E.g. If you achieve a safely validated program with 10 threads, you can consider that as a single block and replicate and connect it to thousands more, and yet your system remains safe from concurrency bugs.
The downside is that its overkill to separate the program into multiple threads just to make sure you don't have shared data.
But it has its merits, imagine you are developing a mission critical system. Its a powerful thing to claim you have a fully deterministic concurrent system with hundreds of communicating threads in it. Also note that cpus will multiply soon to 64, 128 ... cores, so might as well use some of them for something like this.
Atomic operations are not a panacea either. Lock free data structures are very difficult to write correctly and the performance benefits associated with using atomics can start to evaporate when there is contention between multiple threads. There are also numerous subtle problems that can arise, from data visibility problems when modifying an unaligned address on multi-socket x86 platforms to ABA problems.
The easiest to write, and safest, multithreaded code is that which shares no state. Saying that atomic operations are the way to go is like saying NoSQL is the way to go, they are useful for a subset of problems but in general they are the wrong level at which to be thinking when approaching concurrency.
Disable JavaScript and you'll see the slides layed out one after the other, vertically. It was pretty easy to read and skim that way.
(I've been using NoScript and NotScripts for the last month or two and wouldn't go back. Not only is it safe but the web is far less annoying in general. e.g. not hunting around for links to disable IntelliTxt and every other similar "service".)
For anyone wondering, Bell's proposal is each state has its own local variables (limited to the scope of the thread function itself, but I like thread local storage too), and _no_ variables are shared between more than one thread. Any data that needs to be passed between the threads is done via message passing (their so-called "events").
All this would be OK if they had a good reason for it all. Their only excuse is that event loops are inefficient (which I totally agree), and that writing thread-safe code is hard (which I completely disagree with). Using their message-passing system to solve thread concurrency is really not an efficient idea, and it's wholly unnecessary. Wrapper functions, judicious use of your CPUs "Interlocked*" functions to atomically modify or swap variables, and possibly using (yet-to-catch-on) lock-free data structures is the way to go.