Whether UDP or TCP is used, to have a reliable transfer, packets have to be acknowledged. (In the case of UDP, the application itself must generate the acks since the protocol doesn't.) Thus the same reasoning applies as to the other question you referred to.
Saturating the "up" part of your Internet connection slows downloading because packets coming "down" have to be acknowledged by your computer and those acknowledgements have to go out via the up link. If your computer falls too far behind in acks because the up link is choked with data, the sender will slow down and start retransmitting the unacknowledged packets. This will appear to you as a decrease in download speed.
In the past I have had the same effect with my ISP (in a rural area too, though this is but a coincidence).
The root of the matter was that he implemented a bandwidth limitation on port 80 only. This was especially obvious with speedtest.net, where the initial speed would peak, then decrease to less than half of its peak value.
I discovered by pure chance that this did not occur on OpenVPN, where I managed to obtain the peak speed value during the whole speedtest.net test. This was made possible by the fact that the site I connected to (my work site) has a very nice, very fast, large-bandwidth connection.
Alerted by this, I tried a large file transfer via scp, and, lo and behold, I achieved the same large speeds as with the OpenVPN, rather than the lower http speeds.
You may try the same, and see whether a bandwidth limit is applied on ports 22 (scp) and 21 (ftp). It is most illuminating to use files already significantly compressed like pdfs, since this will rule out the incidence of compression per se.
Though admittedly sloppy, these bandwidth limitations are still effective, since most people use the Internet only for downloading Web pages.
EDIT:
Strictly speaking, there is a way to test this: if you control the VPN server, you may stop any other activity on the server on port 80, and start listening for VPN connections on port 80; you will also have to modify the port you connect to on the client's program. Now, if your ISP is limiting bandwidth use on port 80, the VPN should clock at exactly the same speed as the non-VPN connection.
Best Answer
There are a few possibilities - unfortunately, the number of hops is irrelevant.
The first is compression - if the data you were downloading is uncompressed, and your VPN offers compression then this could explain it - however most files transferred are likely to be compressed, so this is not as likely as it would seem at first blush.
The second and third options are related, and have to do with your ISP's connectivity and restrictions. Your VPN has found a faster path to the destination data then directly - which could be because -
The ISP has multiple connections, and the direct connection to the data is constrained. The VPN goes across a different connection, which in turn has better connectivity to the source of the data you are pulling, thus you are routing round the congestion.
The ISP is shaping certain kinds of traffic - possibly by type or destination or both - it could even be by content/payload - but that is less likely. By using a VPN, your traffic is being given priority or not being capped, so you are getting better speed.
There are some other possibilities, but these are again less likely - it could be that the VPN is using UDP while your download would typically use TCP, and different optimisations (MTU for example) are allowing better use of your connection. Again, this is possible, but unlikely - chiefly because you would expect either a much smaller or much greater difference in speed.