Having an immutable ordered log + a single bit flag for "deleted" is radically more efficient than an arbitrarily mutable ordered log.
ex: You could store every tweet compressed in S3 with a bitmap for which are deleted (a bit that can be cached forever). That assumes you aren't going to ever have to update the object in S3. Once you have to update it that entire design is horrible, you'll need something completely different.
Consider that there are thousands of tweets per second with significant fan out for reads. There's search, relationship data (did you @ someone? did your edit remove that @?), business analytics, and more.
Add to that deletion flag a tweet redirect ID. Redirect deleted tweets with the ID to new tweets seamlessly. Touch up the old code to account for all this. Now you can edit tweets with immutability intact.
Also has the benefit that retweets and likes point to the old version, which is how it should be.
oh ok so now instead of 1 immutable bit that can be cached forever we have to store an id. Good news, instead of a wonderfully compressable bitmap you now have a bunch of uncompressable 128bit nullable uuids. Only a few thousand times less efficient!
Oh and of course you now have a linked list structure you have to traverse every time you want to resolve a tweet. Cool.
ex: You could store every tweet compressed in S3 with a bitmap for which are deleted (a bit that can be cached forever). That assumes you aren't going to ever have to update the object in S3. Once you have to update it that entire design is horrible, you'll need something completely different.
Consider that there are thousands of tweets per second with significant fan out for reads. There's search, relationship data (did you @ someone? did your edit remove that @?), business analytics, and more.