This is a new behavior available on Linux kernels since [version 4.19][1] to prevent attacks using `/tmp/` tricks. The default value of the option might have been enabled later or be different depending on the distribution.

> (FEATURED) Avoid unintentional writes to an attacker-controlled FIFO
> or regular file: disallow open of FIFOs or regular files not owned by
> the user in world writable sticky directories, unless the owner is the
> same as that of the directory or the file is opened without the
> `O_CREAT` flag. The purpose is to make data spoofing attacks harder.
> This protection can be turned on and off separately for FIFOs
> (`protected_fifos`) and regular files (`protected_regular`) via sysctl,
> just like the symlinks/hardlinks protection [commit][2]

To paraphrase, this prevents an user to write to a file (or FIFO) not belonging to it when it's located in a world writable sticky directory (such as `/tmp` or `/var/tmp`). This is especially intended to protect the root user which normally always has such write access.

It's enabled with this `sysctl` toggle: [`fs.protected_regular`][3]. One can revert to former behavior with:

 sysctl -w fs.protected_regular=0

but this will likely lower overall security, while making some strange "bugs" like OP's case disappear.

As for why root could still delete the file, that is because the additional security feature is triggered only for opening a file for writing, not for unlink-ing it: `truncate -s ...` does open the file for writing, `rm` doesn't (it uses `unlink` or `unlinkat`).


 [1]: https://kernelnewbies.org/Linux_4.19#Security
 [2]: https://git.kernel.org/linus/30aba6656f61ed44cba445a3c0d38b296fa9e8f5
 [3]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/admin-guide/sysctl/fs.rst?h=v5.15#n239