It's already possible right now to put a contiguous CP image into the block chain if you can mine a block, since large-data-containing transactions are nonstandard, not invalid. And you can put a non-contiguous image into the block chain right now very easily through various difficult-to-prevent and often very harmful methods, as others have mentioned. The Bitcoin Core change won't allow these things, and Knots doesn't prevent these things.

I can definitely see the possibility of political issues here. Although it's not a real difference, people will have much stronger feelings about a contiguous CP image in the chain than a non-contiguous image; a non-contiguous image is a lot easier to ignore. So when a contiguous image does inevitably end up in the chain, there's going to be a lot of fallout from that. If there's overwhelming pressure to censor certain block-chain data, such that a very large number of economic actors feel the need to do it, then that would be a centralizing force, both because it'd become difficult to independently verify the block chain anymore, and because someone will be identifying transactions-to-be-censored. (Again, someone putting a contiguous CP image in the chain will inevitably happen at some point regardless of the Bitcoin Core change, though the change might make it more likely to happen sooner.) Furthermore, it seems quite likely that after the change, when someone inevitably puts CSAM into the block chain, a narrative will develop that "those incompetent Core devs allowed this to happen! We warned them, but they didn't listen!" That just feels like a really easy-to-spread narrative, even though it's based on a completely false premise.

But I tend to think that it is in fact proper for the Bitcoin Core devs to ignore political considerations, and only consider technical arguments. It's not as if the Tor devs considered abandoning the idea of hidden services because some people would use them for evil, and this would make life more difficult for Tor devs and node-operators. If you want political money, use dollars.

However, I have to say that I'm not sure that I totally buy the technical arguments for removing these standardness limits, since direct onchain data storage is generally harmful. Even if nonstandardness doesn't hard-prevent anything, it slows things down a bit, and at least historically miners have used standardness as "good-practice guidance". I don't really want to use my node's bandwidth relaying wastefully-large transactions. But there are far more people-I-trust who support the change than oppose it, and I do acknowledge their arguments. It'd be difficult to argue for a softfork banning OP_RETURN data storage entirely, for example, since that'd just force people-wanting-to-do-that to do it in much more harmful ways. Also, Bitcoin Core has far more review than Knots, and Luke is sometimes a bit unhinged, so I'd be reluctant to recommend Knots for any production use. For now, I'm planning to run Bitcoin Core 30.0 with datacarriersize=1024.