The main reasons to store data are for safety and legal purposes first, diagnostics second. Collision data are all three. They need to be prioritized above virtually everything else on the system and if your vehicle has had so many collisions that the filesystem is filled up, that's a justifiable reason to have a service visit to delete the old ones.
If I were implementing such a system (and I have), I could see myself deleting the temporary without much thought. I would still have built a way to recreate the contents of the tarball after the fact (it's been a requirement from legal every time I've scoped such a system). Tesla not only failed to do that, but avoided disclosing that any such file was transferred in the first place so that the plaintiffs wouldn't know to request it.
The tar file is a convenient transport mechanism for files that presumably exist in original form elsewhere within the system. (All bets off if sources for the tar were changed afterward.)
Given storage is a finite resource, removing the tar after it was confirmed in the bucket is pure waste.
I'm not sure whether you're saying that the tar should or shouldn't be deleted. Regardless, my point isn't that it was intentionally deleted. I can easily imagine someone writing a function to upload the data using something like std::tmpfile (which silently deletes the file when it's closed) without thinking about the full implications of that for the broader context the code exists in.
Even in that case though, you would still have a way to produce the data because it would have been specced in the requirements when you were thinking about the broader organizational context.