Basically, he claims that our existing approaches to security have failed. "Chasing attackers" by closing security bugs once they're published will never really result in a secure system; programmers just keep adding new bugs as the old ones are found. Firewalls, virus scanners, and other "band aids" don't really fix the underlying security problems, and just add a new layer of complexity for system administrators.
More controversially, he claims that restricting privilege is not as worthwhile as is generally thought. I'm not sure if I completely agree with this, but I will say one thing. In the absence of a LSM, the privileges of a process running as you are pretty high! It can read everything in your home directory, add code to your .bashrc, send messages over DBus, etc. From the perspective of an attacker, /home is where the good stuff is, and not having root may not really be a big deal.
Bernstein's proposed solution is to minimize the amount of "trusted code" by putting most of the program in some kind of sandbox. Using seccomp or running software in a virtual machine are two ways to sandbox code. He also wants to minimize the overall amount of code, to make it more auditable.
Generally, sandboxing code involves restructuring a program in terms of multiple processes that communicate over some IPC channel. This has some other advantages, since we're soon going to be living in a world of 64 or 128-core consumer CPUs. Programmers who really care about performance need to start thinking about parallelism anyway.