To @stwenhao's excellent post I only wanted to add one aspect which often is overlooked.

OP_RETURN is always "cheaper" for the whole system than the Taproot envelope, i.e. it consumes less ressources. This is because the Taproot envelope always takes more bytes than the same data in an OP_RETURN output because the Taproot envelope needs an additional output from another transaction for the Taproot script hash, which often results in needing a complete additional transaction, but even if you add the hash to a transaction you would have done anyway (e.g. make a payment and add the hash as an additional output, which I believe almost nobody does) then the script hash adds (afaik) 32 bytes which would not have been necessary if you used an OP_RETURN transaction.

This means: For the full nodes, OP_RETURN is always, even if you have a NFT with 4 MB, the least resource-consuming option. The Taproot method is only "cheaper" regarding fees, due to the witness discount. (Of course this applies when all transactions are generated optimally, without additional unnecessary outputs.)

In addition: One of the reasons why the witness discount (data in the witness has 4x less weight) was applied is the idea that witness data can be aggregated in the future, making blocks smaller. This is true for some other kind of witnesses like those containing Schnorr signatures. But Taproot "envelopes" used for data storage impede the aggregation if I'm not missing something. Imagine a block with 2000 transactions, for 1800 of them perhaps the signatures can be aggregated and compressed to <1% of their size, but 200 "Taproot envelopes" would have to stay as they are. This would mean that the Taproot envelopes, even if small (like in BRC-20 or similar formats) would take a completely disproportionate amount of space in the witnesses.

So Taproot envelopes "get in the way" of this specific scaling idea. That's not true for OP_RETURN because there the data resides in outputs.