I feel that the VNC protocol gets a bad reputation because of bad implementations. There's really nothing in the protocol itself that keeps it back.
What I like about VNC is that you can actually read the RFC and get fairly a good understanding of it in less than a day. I'm not sure if the same can be said for RDP.
Microsoft has this page where you can access a bunch of PDF documents that describe RDP in some sense, but I've no idea where I would even start and/or what's even relevant for any given problem that you might want to solve.
When I had to choose my remote desktop solution, I've tried all the FOSS ones, and they're been a disaster, without any exception.
I've tried I think a couple of VNC-based solutions (since I've tried the most common, TigerVNC was very likely one of them), and they were extremely slow - I can't remember how fast, but something like 1/2 FPS.
This left me very perplexed, because on a 10 Mbit network, with 25-ms ping, a protocol must be very badly designed (or, to be more precise, very antiquated) to have such bad performance. So IMO, the bad reputation is justified.
Other FOSS solutions weren't better, in one way or another. The other one that worked out of the box was X2Go (based on NX 3), which was still very slow (and it seems to be abandoned nowadays).
Sadly, I had to move to a closed-source solution.
Closed source solutions are so fast that sometimes I forgot that I'm on a remote machine. I'm very puzzled why there is such a large gap between open and closed source solutions.
Admittedly, because of VNC's age, there are many sub-optimal encoding methods available and many different implementations which might not be fully compatible with each other. So, maybe your chosen server has some good encoding methods available and maybe the client can support some good encoding methods, but the intersection of supported encodings might be bad.
Users of VNC often need to understand how to tweak their settings for the best result. The client should choose the "best" encoding automatically, but this cannot be fully relied upon. On a slow network (like yours), it's probably best to select "tight" encoding, allow lossy compression (jpeg) and turn down the quality a bit.
That is to say, if the implementation that you're using doesn't support h264. Currently, there are not many that do.
At least some commercial remote desktop solutions are very strict about business usage - they don't allow it at all (last time I've checked, Teamviewer was so).
Nomachine is a bit looser: they allow occasion business usage, as long as it's not the core of the remote workflow.
It certainly has its place, but as a remote desktop solution it is the simplest (and stupidest) way that functionality could possibly be implemented. VNC is what you use if you want to copy whatever is on the screen of the remote system, RDP is what you use if you want your displays connected to a remote system.
RDP lets you use all of the client's monitors, printers, clipboard, audio, USB devices, etc. as though they were plugged in to the host. The clipboard sharing extends to files, so you can drag and drop a file from the client to the host via the RDP window. If you lock your workstation at work with a bunch of running programs, drive home, and RDP into it, all of the applications will be moved to your RDP session and rearranged to fit your display(s). The next day you log back in at work and they get moved back to the local displays.
Oh, and did I mention all of this works well even on crap connections? I have been at jobs where a remote branch has such shit internet that they RDP into a VM at the head office to browse the internet because RDP uses less bandwidth than the sites they are browsing.
Free VNC implementations often lack modern features that make the protocol usable. I've yet to find the first VNC interaction where my password can be longer than 8 characters. Everyone seems to just tunnel VNC over SSH instead of implementing modern authentication protocols which adds another layer of complexity and limitations to a latency sensitive, high-bandwidth protocol.
VNC is definitely easier to understand but the common servers usually leave a bad taste in my mouth after using them. RDP clients are often higher quality but there are many issues with (configuring) RDP servers right for Linux; however, GNOME's direct RDP integration has solved a lot of problems I was having before.
I feel that the VNC protocol gets a bad reputation because of bad implementations. There's really nothing in the protocol itself that keeps it back.
What I like about VNC is that you can actually read the RFC and get fairly a good understanding of it in less than a day. I'm not sure if the same can be said for RDP.
Microsoft has this page where you can access a bunch of PDF documents that describe RDP in some sense, but I've no idea where I would even start and/or what's even relevant for any given problem that you might want to solve.