The OP_RETURN limit increase (which is a standardness/policy increase, to those who don't known, not an increase of some consensus limit) does
not create additional incentives to store arbitrary data on the blockchain.
In other words: It doesn't get cheaper to create NFTs and similar stuff with Core 30 than with Core 29.
So it's extremely unlikely that "VC capital" is behind that move. Why should they pay the developers if all tools they need are already at their disposition, and the limit increase does
not make anything cheaper?
The topic has been discussed at nauseam, and the problem is always the same: there is no way to stop data spam, you can make it a bit more expensive but then you would have to cripple a lot of other use cases, like Lightning, and as far as I know you would also need to store more data on-chain in "real financial" transactions.
Contiguous vs non-contiguous illegal data is not really relevant. If you store the data inside P2PK outputs (a kind of the "fake public key" method available since 2009) it would probably even "look" like image data with some dots here and there. Transactions are not stored in JSON format

.
Short example: We have a random data string which could contain an image and is currently non-standard as an OP_RETURN in BTC 29 ...
af193e9191dc485bbb5c516e43bff608bdd6de08365a4e3e827b314dff718dcb67672a3a837547b6bab3b33f632fb2b431d82c14d8d14326888ba3c4b72902ac681
ef39658f847e9b84c99e22dd63fe62a106df9e2f64987a2bd0ee4be3a86bc445459c1d529475ba3eb061744c7d1383420a22b0457419d810b2975fbc082ec
Posting it as a series of P2PK outputs (the 0s at the start are the values, and the 43 is the script length of 67 bytes of the script, 65 for the pubkey and 1 for each opcode):
0000000000000000
43
OP_PUSHBYTES_65
af193e9191dc485bbb5c516e43bff608bdd6de08365a4e3e827b314dff718dcb67672a3a837547b6bab3b33f632fb2b431d82c14d8d14326888ba3c4b72902ac681
OP_CHECKSIG
0000000000000000
OP_PUSHBYTES_65
43
ef39658f847e9b84c99e22dd63fe62a106df9e2f64987a2bd0ee4be3a86bc445459c1d529475ba3eb061744c7d1383420a22b0457419d810b2975fbc082ec000000
OP_CHECKSIG
Which results in the following inputs (41 is OP_PUSHBYTES_65, ac is OP_CHECKSIG) :
00000000000000004341af193e9191dc485bbb5c516e43bff608bdd6de08365a4e3e827b314dff718dcb67672a3a837547b6bab3b33f632fb2b431d82c14d8d14326888ba3c4b72902ac681ac
00000000000000004341ef39658f847e9b84c99e22dd63fe62a106df9e2f64987a2bd0ee4be3a86bc445459c1d529475ba3eb061744c7d1383420a22b0457419d810b2975fbc082ec000000ac
We see: The "obfuscation" by using P2PK instead of OP_RETURN is not really relevant. Those distributing illegal material would be happy if it was enough to add a couple of zeroes, and an "43", an "41" and an "ac" here and there.
And if it really was relevant: would "VC Capital" not be aware of this potential danger? Why would they bribe Core -- as I wrote above, they have already all the tools to store NFT collections almost as big as they want, even using cheaper means?
Doesn't that contradict the whole bribery complot story?
This may be a deliberate attack on Bitcoin using some users' emotions and the mechanisms of social media, to cause confusion and later establish a new development team without any Cypherpunk values left. That's my (not entirely serious) conspiracy theory, but it is even more plausible than the bribery theory

A in-depth solution to the "spam problem" would be a different way to store the blockchain, where no full node would need to store OP_RETURNs anymore, nor any outputs in raw form. Utreexo is already a step in that direction, but still we need archival nodes for the block data. It should however be possible with zero knowledge techniques to ensure an initial block download without any real transaction data. AFAIK some altcoins have already achieved this.
BTW: if I already mentioned altcoins, shouldn't be Ethereum or Solana now be full of illegal data if everything can be stored there already? I don't care about them, but that this doesn't seem to be a problem makes the fears around Bitcoin 30 even less convincing.