⭐ Merited by JayJuanGee (1)
That experiment effectively stored a NEGATIVE amount of data in Mimblewimble transactions. In order to locate each 2.5 bytes of data, the extraction needs to know the ID of every kernel in which data was stored, and their correct order. The data extracting program [1] uses 70 bytes of source code to locate each 2.5 bytes of data.
Yes, I knew about that. That's why I'd be interested if there were attempts which were successful in the sense that non-negative storage was achieved, even if it was expensive.I wonder however: couldn't be the same techniques to use for "scriptless scripts" also work for data storage?
*Possible* - I don't know if it fixed all the possibilities, but it certainly addressed the main one that was being abused.
Please do your homework and read either this thread or the mailing list discussion (at least the first message there). One has to repeat and repeat things like a parrot it seems 
As ABCbits already wrote the main problem is that besides from OP_RETURN there are more harmful ways to store data. The way you mentioned (Taproot witness abuse) is only slightly more harmful than OP_RETURN, but the remaining case, fake public keys, is the real problem -- if we had a real spam wave with these techniques, this could become a serious problem for decentralization due to UTXO set bloating.BTW thanks @uint512 for the nice analogy:
[...] breaking into computers or spamming protocols is as bad as breaking into other people's houses.
Let's say we stay with this comparison: your node resources are your "house" and those "breaking in" are the data spammers. In our analogy, they are intruders which use your house for their benefit as a storage deposit. Now let's see how the different methods affect your house:1) In the case of OP_RETURN, the intruders break in into your house and deposit a big thing like a grand piano in a place where you can ignore it, like your cellar. Of course it's annoying that you now have less space there. But it doesn't get in the way that much and you can remove it after a couple of days (=pruning), and if technology advanced a bit more (=alternative blockchain storage methods), you could remove it almost instantly.
2) In the case of "fake public keys", the intruders also store a piano of ~ the same size in your house, but they put it in your living room where you can't ignore it. Not only that: they also place a smaller upright piano into your kitchen (the UTXO set). You can remove the grand piano in the living room after some days like in the OP_RETURN method (=pruning). But the piano in the kitchen will be there forever, getting constantly in the way when you want to cook.
3) In the case of the Taproot exploit, it's a bit like a lottery. If the intruders are professional "piano spammers" the situation is similar as with OP_RETURN. But many aren't that professional. So they may also leave a piano in your kitchen (if they create dust outputs with their transaction).
Now the big problem: You can filter methods 1 and 3 (sort of), but not method 2, which is the most annoying one.
If the (armed) intruders are knocking on your door, wouldn't you beg them to use method 1 or 3, so at least you can use your kitchen in peace? That's what the devs would be doing if they remove the OP_RETURN limit.