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]

This affects only files in a directory not already owned by the user attempting to write (and not a `+t` directory). This is especially intended to protect the root user.

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" disappear (example: if `tcpdump` changes to user tcpdump for security reasons, the same `tcpdump` command writing twice to `/tmp/mydump.cap` will fail the 2nd time because the file is owned by `tcpdump` and not root and the command didn't make provisions for this case).

As for why root could still delete the file, that is because the additional security feature is triggered only for opening a file without using the `O_CREAT` option (using it would already fail on its own), not for unlink-ing it: `truncate -s ...` does "open the file without `O_CREAT`", `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