The man page lists 5 limitations of the --inplace option, one of those is:
(4) a file that does not have write permissions can not be updated
A small enhancement of the man page would be to specify that this limitation doesn't count for the root user. In other words the limitation is not that rsync would check the file permissions and refuse if it doesn't have +w, instead rsync simply tries to write anyway and if that works (i.e. the user is somehow allowed to write to that file regardless of file permissions) all is well.
In my case, /etc/shadow can in fact perfectly be backed up with rsync --inplace, despite the -r-------- permissions. In order to be able to read that file, rsync was running as root anyway.
Secondly, the man page gives a hint for possible use cases of --inplace:
This option is useful for transferring large files with block-based changes or appended data, and also on systems that are disk bound, not network bound.
A use case that will become more and more relevant these days and in the near future is the use of copy-on-write filesystems, that also support snapshots, like btrfs. In that context using --inplace can seriously increase disk space efficiency, because the fs then only has to store the changed blocks.
Thanks -- I've clarified those issues in the master branch of git.