> My main concern with OP_RETURN is that it seems to encourage people to use the blockchain as a convenient transport channel

The number one user of the blockchain as a storage and transport mechanism is Counterparty, and limiting OP_RETURN to 40 bytes didn't prevent them from doing so. In fact they use multi-sig outputs which is worse than OP_RETURN since it's not always prunable, and yet let them store much more than 40 bytes.

For Open Assets, we need to store a URL in the OP_RETURN output (with optionally a hash) plus some bytes of overhead. 40 bytes comes really short for that. The benefit of having a URL in there is that any storage mechanism can be used (Web, FTP, BitTorrent, MaidSafe...), whereas with only a hash, you have to hardcode the storing mechanism in the protocol (and even then, a hash is not enough to address a HTTP or FTP resource). Storing only a hash is fine for the most basic timestamping application, but it's hardly enough to build something interesting.

I've counted the number of OP_RETURN outputs in the blockchain for the month of October 2014. There were 1,674 OP_RETURNs for a span of 4,659 blocks. Assuming they were all 40 bytes (the average is probably less than half of that), that means an increase of 14.37 bytes per block. Considering a 1 MB block, that's about 0.0013% of the block used up by OP_RETURN data in average.

Increasing to 80 bytes will have a negligible impact on bandwidth and storage requirements, while being extremely useful for many use cases where a hash only is not enough.