Going local is fastest and most efficient for your question, so (1).
This all involves how your packet gets routed through your network.
The difference I can identify immediately from your simple description here is using a gateway versus going directly to the PC. By going to the external address, you will use the router (default gateway) and its resources in order to make the connection. If this router is being heavily utilized you will notice a significant reduction in your traffic throughput.
I'd first suggest checking out your routing table on the local system
user@server:~$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.11.0.1 0.0.0.0 UG 0 0 0 eth0
10.11.0.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0
You can see with my configuration that if I reference a system on the local network (i.e. 10.11.2.200) it will go directly to that system. If I have a NAT address for it (i.e. 10.11.2.200 NAT www.somedomain.net) it will first travel to the router and then NAT back into the network.
You can test this out by running a traceroute to the internal IP address and then compare it to the NAT'd IP address. (It is preferrable to disable name resolution on your traceroute).
user@server:~$ traceroute -n www.xxx.yyy.zzz
traceroute to www.xxx.yyy.zzz (www.xxx.yyy.zzz), 30 hops max, 60 byte packets
1 10.11.0.1 0.598 ms 0.717 ms 0.792 ms
2 10.10.1.3 0.710 ms 0.788 ms 0.896 ms
3 www.xxx.yyy.zzz 0.609 ms 0.496 ms 0.439 ms
You should notice you go to your default gateway (router) before returning back into the network.
Compare that to your direct traceroute
user@server:~$ traceroute -n 10.11.0.64
traceroute to 10.11.0.64 (10.11.0.64), 30 hops max, 60 byte packets
1 10.11.0.64 0.349 ms 0.343 ms 0.336 ms
The reason why the small file transfer speed was noticeable is because of its extremely small size which took time to allocate the resources on the router. On a larger file transfer the time will be statistically insignificant since you are opening up a connection and leaving it open. A test that would give you different results would be sending the small size file, but running it X number of times to equal your 100MB file size. Try that with a script executing the command 20,000,000 times should get you 100MB.
cmd="ssh ... echo hello"; for ((i=0;i<10000000;i++)); do $cmd;done
(10,000,000 executions because 'echo_hello' is 10 bytes in, though the output is more than what would be received from a simple ACK packet for the SCP). This script is just a quick proof of concept.
I hope this solves your question correctly. I would like to add this gets more complicated if either the source and/or target system has multiple interfaces on different networks.