Still don't follow. You are still using the same "packet" thingys when you copy the file. So there is an equal chance for a dropped packet to cause corruption.
Now add in the fact that you must first place the file on the local machine, involving the disk controller and the drives, then go back and read the exact same data back from controller and drives, then shove it through the same network adapter, etc.
You've added a lot of places where corruption could occur. And as Mohammed indicates, the SQL server will know about the network problems during the backup. "Later on" is too late when the LSNs get updated for the next transacton log backup.
I'll stick with the direct-to-network approach. I've backed up 50 GB/day for 5 years over the network without a problem.
And I do test my backups regularly.