To put things simply, one of the goals of U-Prove is to provide some kind of anonymity (in their words, "preventing unwanted user tracking"). This makes revocation harder. In an X.509 context, where there is no user anonymity (a certificate contains the owner's name in plain words), revocation is simple: the authority who decides who is revoked and who is not simply issues signed statements about the revocation status of a given certificate. This can be an OCSP response, which talks about a single certificate, or a CRL, which lists all revoked certificate (from a given issuer or set of issuers), and thus implicitly lists all non-revoked certificates as well.
If you try to do the same thing in U-Prove, then you have invented a way to track users, and that's not good. So revocation in U-Prove must use more complex protocols, e.g. a cryptographic accumulator. Mainly, this allows each token owner to compute a verifiable proof of a token not being revoked at a given time, without opening the possibility of tracking the token owner. Revocation is still asserted by a specialized authority, so there must be some regular communication from the authority to the token owners; these are the witnesses. Each token owner must obtain a fresh witness from the authority, in order to compute the verifiable proof that the specific token is not revoked at some time.
This is not an optimization over X.509 CRL/OCSP. In an X.509 world, each certificate owner can obtain a fresh OCSP response from the CA and then show that response to third parties; this mimics the system of witness propagation but with shorter elements and less CPU cost. Moreover, in X.509, it is not necessary that the certificate owner be involved at all; each entity who wants to validate a certificate can obtain the CRL or OCSP response directly from the CA.
In other words, cryptographic accumulators don't make classic revocation more efficient. In fact, they make it less efficient. But they add a new feature, which is the possibility to maintain revocation while still pursuing a non-tracking anonymity goal. This goal makes no sense in X.509. Therefore, no cryptographic accumulators in X.509. You could try to design and implement a revocation system for X.509 which uses cryptographic accumulator, but it would provide no extra feature, and would just make the system more complex, expensive, and restricted.
(In shorter words, there is no revocation scheme for X.509 which uses cryptographic accumulators because it would be a stupid thing to do. It would be like adding an extra gasoline tank to power a horse-drawn cart: it would not help the horses go farther, even though it would have helped if the horses had not been horses, but a combustion engine.)