Why isn't the rsync 'inplace' trigger used for backups?

Backintime uses hard-links for incremental backups. A file that did not change since the last snapshot will be linked to the same inode as the last snapshot. The inplace trigger would change the data of that inode instead of creating a new inode that is only referenced by the file in new snapshot. So the old snapshots would also be changed.

Regards,
Germar

Is there no way to implement this in a smart way? It would drastically reduse the bandwith required for backups.

The bandwidth use of rsync is the same with or without inplace. Only the IO writes attempts on the destination would be lower with inplace.
But if you use some kind of remote filesystem (nfs, samba/cifs) for backup destination the higher IO write attempts will result in more traffic. That's right.
If thats the case I would advice you to try out the new version from PPA with SSH support and 'Full rsync mode'. That will increase speed dramatically. In SSH-mode rsync will use its delta-sync magic and only transfer those parts that has changed.

Yeah, I noticed the new remote backup feature. Great job on that btw!

For the time being I'm backing up to an external drive and the most time consuming process is copying the big files that change. Would be great to minimize that as much as possible and as far as I understand inplace would help with that. Or am I mistaken?

Ja, you're right. Inplace would speed that up. But as I said it would also break BITs concept of making incremental snapshots with hard-links. We need to have a physical second copy of the data and that takes time and space.
This concept of BIT has a lot of benefits (e.g. that you can access you backup without any special tools) but for big files where only a few blocks are changed BIT is not the best solution because beside the time issue this also waste a lot of space.

I'm sorry to say but for those files it would be better to use a backup solution which is based on something like rdiff or duplicity. They only store the difference between the old backup and the new file.