You misunderstood the parent post, it's extremely difficult to delete the data without leaving a trace that something was deleted.

To reliably delete a specific file or directory, it needs to be encrypted with a dedicated key which can be reliably deleted. It can have dedicated key material in the secure element used to derive sub-keys from the main encryption keys or it could simply be encrypted with another layer of encryption.

For the OS disk encryption, it uses separate randomly generated disk encryption keys for the main user, secondary users and Private Spaces which are different forms of profiles. Those keys are stored encrypted with key encryption keys derived from the per-profile lock method combined with various forms of key derivation material from elsewhere.

The most important of the key derivation material for profiles is the per-profile Weaver token on the secure element which it uses to enforce rate limiting for decryption attempts (max 20 attempts per profile with rapidly increasing delays) and to provide extremely reliable deletion of the data. Wiping the weaver slot for a profile prevents deriving the key encryption keys which prevents ever decrypting the randomly generated disk encryption keys again. The randomly generated disk encryption keys are only stored once and get wiped via a special SSD secure erase command but that isn't nearly as good as the secure element integration. If the SSD is imaged before a wipe and then restored, the data still isn't recoverable because the secure element wiped what's needed to decrypt the disk encryption keys.

Reliably deleting data is a much different thing from fully hiding that anything was deleted which is drastically more difficult and not compatible with how things are typically done. It's pretty much impossible to stealthily delete a secondary profile since there's too much system and Owner user data referencing them including the package manager's state, battery stats, data usage stats and far more. It's possible to attempt to go through all of that and hide it including forging the other stats to mask what was removed but data cannot be reliably deleted in a fine-grained way, especially on top of a modern copy-on-write or log structured filesystem combined with an SSD controller doing wear leveling.

An SSD controller will redirect writes to less written NAND than what is now being written to level out usage. That relies on it being aware of free storage to choose from that instead which is the purpose of TRIM. A modern SSD will also very proactively move around data rather than only redirecting writes to free space with less wear. It will identify the data that's rarely or never written and move it to the most written areas of the SSD to free up the space it was on for the most written data. Having 2TB of used space that's rarely ever touched, 1TB of a heavily written database and 1TB free will not only use the 2TB of active space for wear leveling with a modern SSD controller design. It will use the whole 4TB for it.

A modern copy-on-write or log structured filesystem doesn't write to the location where the data was originally but rather elsewhere. Android uses f2fs which is log structured which heavily helps with wear leveling at a higher level and also provides the ability to turn off data persistence temporarily and then roll back to the point it was turned back in an incredibly efficient way. Android uses that incredibly efficient rollback feature as part of A/B updates to preserve the ability to fully roll back an OS update which doesn't end up working properly until after it reaches the lockscreen successfully.

An app regularly appending data to a file, overwriting data in it or replacing the whole file is leaving data around all over the place. A decision can't simply be retroactively made to reliably delete the data for that file or the overall app. It would have had to be set up in a way that it can be reliably deleted. Without that, the whole secondary profile it's in is going to need to be deleted to reliably delete the data. If it's not in a secondary profile, the whole device needs to be wiped for it.