In theory the load on the remote server will (by aggregate) be the same. It is the same amount being downloaded from one server and the same amount being uploaded to another, but the focus point of that load is shifted.
From your link:
By offloading the copy to the server it becomes the server itself that does the copy. For two servers in the same datacenter it can be a lot faster, as the copy can happen at the local datacenter link speed. If you have a 10mbps connection to both servers, but they have 10gbps local connections, then copying locally will be incredibly slow by comparison. It might cause a higher instant CPU or network load, but the transfer can happen faster. It might even be that the transfer is more efficient, due to lower latency caused by various network appliances in between you and the server.
As mentioned in that link by offloading the copy to the server itself you almost entirely remove your local machine from the equation:
A source file and a destination file can be on the same volume, two different volumes hosted by the same machine, a local volume and a remote volume through Server Message Block (SMB2 or SMB3), or two volumes on two different machines through SMB2 or SMB3
So it doesn't matter if it is the same server, or different servers, the copy operation will be a lot more efficient and will use whatever is available.
On a server or cluster with deduplication a copy might be effectively zero cost in terms of both CPU and disk time as no actual file data would need to be copied until changes were made. Only a file reference would need to be created. In this case using
/NOOFFLOAD would be a massive waste of resources as you would download the data and re-upload it, while forcing the server to recheck and de-duplicate the data.
Disabling the offload will force the download to go through your machine. You will download the data from one server and upload it to the other. There are some situations where this might be desirable, particularly if you know that you are in between two servers and have a more effective link, perhaps with less routing or management appliances.