Short answer: you're assuming the data exists to validate at all client-side. Unfortunately that's not something you can assume. If you're just putting hashes of Counterparty data in the blockchain what is a client supposed to do if they can't find the corresponding data? If they assume it doesn't exist then you can be sybil attacked by someone who later reveals the data and changes the consensus out from under you. On the other hand, if you assume it must exist, and wait until you find that data, a trivial attack is to put fake hashes of alleged counterparty data in the blockchain.
You wouldn't have to solve any problem if your chain validated your transactions. You wouldn't need to bloat your chain with open orders like mastercoin and counterparty (if I understand correctly) do.
Colored coins don't put the open orders in the chain, but not all colored aspects of a colored coins transactions are validated.
If your chain validated all you need it to validate, you could even have SPV clients consuming a committed UTXO (something non-hardfork colored coins cannot give you).
I don't know mastercoin and counterparty deeply but I believe they use "accounts" (like ripple.com) instead of inputs/outputs (like bitcoin and freimarkets), which is another design mistake.
Too many efficiency sacrifices only to avoid bootstrapping your own chain like namecoin did when it wanted to support additional features.
If we all bitcoin users want to support these features in the bitcoin chain, there's a better way to do it: a hard fork.
I'm all for this features (asset issuance, p2p trade, ripple-like transitive trades, options, etc) in Bitcoin's main chain myself, but the right way.