You would be correct in your assumption. The backup process uses the Linux TAR (short for “Tape ARchive”) command to take the contents of your config folder and database and consolidate into a single archive file. The TAR process, by its nature builds the file locally in a temp directory, and then will copy the completed file to its destination. Likewise, if it was using GZip compression (which at least looking at my backups HA is not), then the TAR process would take a second pass at the file to compress it before the copy.
TAR operates with the presumption that its destination will a tape drive - a process which is much slower than the fixed disks, and likewise is very linear in its storage, so it was much more efficient to do these activities before writing to the destination.
I have several dozen servers in my day job that use TAR for backups, and they all behave the exact same way. I don’t see the HA team building a new backup method just to reduce local disk I/O when the existing one is widely supported. The other option would be to force TAR to use a RAMdisk, but considering my modest HA instance has 2.2GB backup files, it would put most Raspberry PI’s out of the mix for supportability.