sounds like possibly it was to try to play it safe in case something went wrong. But using it has perils:
Repair command deletes remote files for new backups #3416
and if compact has run, the new files in the remote will be even less recognizable to the obsolete DB.
I think this is another of the timestamp precision issues. The remote dlist uses one second resolution, whereas the database uses whatever local filesystem (and in some cases, version of mono) will give, meaning all files on some systems will look a fraction of a second newer, and get scanned to be sure.
Watching About → Show log → Live → Verbose may show a lot of lines going by that look like this:
2020-01-28 11:48:11 -05 - [Verbose-Duplicati.Library.Main.Operation.Backup.FilePreFilterProcess.FileEntry-CheckFileForChanges]: Checking file for changes C:\pathname, new: False, timestamp changed: True, size changed: False, metadatachanged: False, 12/25/2019 10:17:20 PM vs 12/25/2019 10:17:20 PM
If you really want, you can open the database and see FilesetEntry.Lastmodified (100 ns resolution) looking nice and even after Recreate, but after Backup it’s a fraction of a second higher than before.
This won’t occur on ext3 filesystem which has one second resolution, but several FSs can do better.
I think ls -l --full-time and stat will reveal fractional seconds, if you’re unsure if they’re there.