No, it's not, it's a silly point.
Bitcoin includes transactions because it validates the data inside them.
Bitcoin clearly does not validate Counterparty data. I am free to include Counterparty data in my own transactions at any time. I am free to spend Counterparty coins to myself at any time, etc. Bitcoin doesn't care.
The level of validation performed by the bitcoin network is the same, whether full counterparty data or a simple hash is in the blockchain.
Long answer: re-read my paper on about
proof-of-publication and how Bitcoin mining really works.
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.
Now you can try using something like the zookeyv concept I wrote about in #bitcoin-wizards last summer - I remember you saved a copy of that discussion - but then you run into a simple economics problem: if you can attack an individual system in one go, the cost required for security is going to be very high compared to the cost per transaction. Thus it's best if you spread that cost across multiple systems/uses, and force any attacker to attack them all at once. Anyway, this is all pedantic: Counterparty gains enormously in security by using the Bitcoin blockchain, and there's fuck all that Bitcoin can do about it if the Counterparty devs encode their transactions correctly.
In fact, here's a really good test to see if you understand this stuff: Suppose P2SH^2 was implemented and everything other than pay-to-pubkey-hash transactions was disabled. How can embedded consensus systems take advantage of P2SH^2 to survive without resorting to the brute-forcing parts of the hash to encode the data and without resorting to using any data embedded in any part of the transaction other than the scriptPubKey? If you can guess why, you'll be a lot closer to understanding what proof-of-publication actually is; I'll give 50mBTC to the first person with a correct answer.(edit: unless your name is Gregory Maxwell! already told him) I'll give you some further hints: the solution in this scenario ends up creating huge amounts of unspendable outputs in the UTXO set, it is blocked by Gregory Maxwell's "P2SH^2 v2.0" idea where hashes can self-prove their hashes without proving a pre-image explicitly, and finally is actually cheaper for the embedded consensus system modulo the IsDust() rule.
I don't know if this meets all of the requirements stated, but based on a quick skimming of P2SH^2 and your Proof-of-Publication paper, here's a rough idea of an "attack" to store arbitrary data. This would require a tiny amount of brute-forcing, and it is not dust/fee-efficient, but I think it would work. I was unable to find the "2.0" discussion.
Say we want to send information ABCD. The sending address is X_1. All we have to do is find a fake P2SH value whose hash starts with (A). This creates a transaction, X_1 -> AXXXXXXXXXXXXXX (unspendable, but is a valid hash of a seeming hash, so it's likely un-detectable). Change is sent to X_2, a valid address. X_2 sends X_2 -> BXXXXXXXXXXXXXX, change is sent to X_3. X_3 -> CXXXXXXXXXXXXXX, change to X_4. X_4 -> DXXXXXXXXXXXXXX, change to X_5.
Clients can decode the proper byte-ordering because change address X_2 only contains coins after the X_1 transaction, X_3 only after X_2 transaction, and so on.
It's also possible that a dedicated Counterparty user or group of users could spend some hashes coming up with actual addresses that can create the A, B, C, D hashes. They could pre-generate an "alphabet" of addresses which would allow them to recover the BTC, excepting tx fees. If the user had enough BTC coins/coin-days, he could even structure each of these transactions so as to avoid tx fees completely. Of course, the risk of doing this would be that such addresses could be blacklisted after several uses.
It is of course possible to encode more than 1 byte per tx. It just requires more hash-time, but I'm guessing that even on commodity hardware, coming up with an "alphabet" of all possible 2-byte pairs wouldn't be much work. Of course, this would halve the number of BTC transactions needed to encode each XCP transaction.