Indeed, so in that case BitVM actually doesn't sound like a better option, since that requires 2*log2(#of_compute_steps) on-chain bitcoin transactions in case of dispute, each transaction possibly ~400vB.

RGB on the other hand, only commits (stores a hash) the off-chain data into bitcoin transactions and does so in the tapscript hidden under taproot address (something we call tapret - OP_RETURN hidden inside of taproot tree). So you can have 1-in 1-out 110vB bitcoin transaction that commits to an off-chain state transition (without using any more data on the bitcoin blockchain - also invisible to chainanal). Even better, you can actually commit to multiple state transitions in a single transaction, so you can do hundreds of RGB token transfers that are committed to single bitcoin transaction of just 110vB (that's what RGB guys mean with scalability). So bitcoin blockchain pollution is super low.

All of the raw state transition data is accumulated only in the off-chain history of the RGB contract, and that's where this 200 bytes per transaction grow is, but again, you only verify a small subset of all those transactions.

In the end, BitVM and RGB are 2 completely different things.

BitVM is good for verifiable off-chain computation in a 1-to-1 channel (like lightning). With RGB you can create off-chain contracts (tokens, NFTs, digital revokable identity, verifiable audit log - like opentimestamps), that are bound to UTXO - so they are composable with everything a normal bitcoin UTXO is composable with - HTLCs, adaptor signatures, DLCs, PTLCs, multisigs.

You can even use BitVM with RGB assets instead of bitcoin!