The factor-of-eight trap
Network links are sold in bits per second; files are sized in bytes. Divide by eight before doing anything else: a 100 Mbps line moves at most 12.5 MB/s, a gigabit link 125 MB/s, 10 GbE 1.25 GB/s. This calculator accepts both bit-rate and byte-rate units and does the conversion for you, the mismatch is the single most common reason back-of-envelope transfer estimates are wildly wrong.
Why the "realistic" row exists
You never get the theoretical number. TCP/IP headers, TLS framing, acknowledgements and retransmissions typically eat 5–10% of raw line rate even on a clean path; the row adds 10% as an honest default. Real transfers can be slower still for other reasons: a high-latency path limits a single TCP stream regardless of bandwidth (the bandwidth-delay product problem, parallel streams or tuned window sizes fix it), storage on either end can be the true bottleneck, and rsync over millions of small files spends more time on per-file overhead than on payload.
Sanity checks this enables
The classics: a 2 TB backup over a 100 Mbps uplink is roughly two days, which is why off-site seeding is done by shipping a disk ("never underestimate the bandwidth of a station wagon full of tapes"). A 500 GB database copy across a gigabit LAN is about 75 minutes, so if your maintenance window is 60, you know before starting. And when a transfer runs at a suspiciously round fraction of expectations (exactly half, exactly a tenth) suspect a duplex mismatch, a port negotiated at the wrong speed, or a single-stream limit rather than random slowness.