One point made about capabilities is that they partially go against the Pythonic grain.
If capabilities were implemented as Python references, you could inherit capabilities (== references) from superclasses, just as you can currently do.
That's why it says "shouldn't" instead of "couldn't". I could re-word this to go more along the way Ping phrased it in how the class statement does not make perfect sense for capabilities but it can be used.
I can't speak for Ping, but I would be quite surprised if he thought that capabilities were un-Pythonic. (I wouldn't be surprised if he disapproved of the notion of classes in a programming language, regardless of security considerations...)
Speaking for myself, capabilities have two main advantages: they fit with the Zen of Python, they enable higher-order least-privilege, and they fit with the principle of unifying designation and authority.
But seriously, I feel that capabilities fit with normal Python programming as it is currently practiced.
http://zooko.com/ ^-- under re-construction: some new stuff, some broken links