There are two problems with that.
First, the system adopted by Counterparty is
hugely inefficient. It won't scale. That's why we're making all these complaints about node validation and SPV mode - because these are what lets bitcoin scale even to the level it is currently at. And Counterparty as implemented lacks this capability entirely - and in such a way that it cannot be retrofitted in later.
Second, Counterparty should be working as Bitcoin developers and using existing Bitcoin code and infrastructure. Writing this sort of consensus code is the same difficulty whether you are doing it as a fork or improvement to bitcoin, or doing it as soem sort of embedded/parasitic system. Really, it doesn't make a difference: you still have to deal with the same sorts of issues in either case. The analogy about code encapsulation is cute but doesn't apply: here there are gains to be made from symbiosis. By choosing to make a separate system Counterparty developers are hurting both Bitcoin and themselves.
In theory, at least. Obviously the current problems are the result of this NOT happening. Bitcoin changed a spec at the last minute, and Counterparty had to adapt in a way that the Bitcoin devs didn't like. Makes me wonder what would have happened if this had simply been kept quiet by the Counterparty devs. If they had just quietly resorted to using multisig (that is what they're using now, right? It's hard to keep up) instead of OP_RETURN, without the furor on this forum, would the Bitcoin devs ever have noticed Counterparty?
I participated in those developer discussions, so let's get something clear: I was not, and I don't think any of the other developers were aware of Counterparty's intention to use OP_RETURN + 80 bytes. If so, there would have at least been better communication about the change. OP_RETURN should only ever be utilized in user transactions as a last resort, and even then as a temporary measure until some other infrastructure could be built, and certainly only for financial data relating to transaction processing. Examples would be 256-bit scalars or compressed public keys and a few bits of prefix data for stealth addresses. It was pointed out that under no circumstances would this exceed 40 bytes, so the rather arbitrarily chosen 80 byte limit was twice as big as it needed to be.
There is not and never has been an adversarial relationship between bitcoin developers and Counterparty developers. If we appear antagonistic, it is because we are being critical of the
design of Counterparty, which is flawed and needlessly detrimental to Bitcoin.