This is a great idea! I love the thought. Unfortunately it won't work, but its good thinking!

Here's the bit that you're missing:
As you may know, taproot lets you construct an address that be can be spent from using either a key (called the keypath) or using one of potentially many scripts (called a script path)

When you construct a taproot "address", you take an internal key (the pubkey that's usable in a keyspend path), and you tweak it with the merkle root of the script tree. So you take all the tapscripts, make it into a merkle tree, and then add the merkle root of that tree to the internal pubkey, and the resulting pubkey is used as the address.

When you spend from a scriptpath, you provide the internal pubkey, the script that you're spending, and a little blob called the Control Block that includes a merkle proof that the script was included in the tweak. The script interpretter hashes the script that you provide, and then validates that the merkle proof in the control block is valid, and then combines the tweak with the pubkey and validates that it matches the address. In other words, it checks that the script that you're using to spend was actually committed to when you locked up the coins. This involves hashing the entire script. If that check passes, then it proceeds to actually interpreting the script (which as you point out it basically a checksig and then a no-op).

So, if you were to prune out the actual data blobs from the inscription envelope, then the hash of the script won't combine with the rest of the hashes in the control block up to the correct tweak, and the transaction will not be seen as valid, and won't be mined.

For the gory details on how this happens, check out BIP341: https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#script-validation-rules

tl;dr: even though the data is not evaluated, it's still hashed, so has to be there for the tx to be valid.