They're equivalent to being root in the case of an arbitrary code execution bug. In the case of a bug that only allows the attacker to cause the daemon to perform a particular unintended operation, they are not all the same as root. There are plenty of potential bugs that can only cause the program to write to an unintended file, and if these programs only have special capabilities that don't directly affect permissions, the use of capabilities has prevented an attack. If, for example, there is a process running as nobody with CAP_SETUID which is secure except for insecure temporary file handling (of the sort where the attacker causes the program to open and write to the attacker's choice of path), the attacker won't be able to use this particular bug to get root. He does mention this, saying that a particular bug may have constraints that prohibit using the bug to execute the transitions that the capabilities allow. (In particular, if cron on his system had an insecure temporary file handling bug, having it not run as root and not with capabilities it doesn't actually have would prevent exploitation.)
Of course, arbitrary code execution is probably the most common end result of security hole, simply because once the program is doing something unintended, this starts violating assumptions and causing more unintended behavior.