Given the huge number of people who work on remote servers, I find it surprising that proper solutions are still so hard to find. A "file system provider API" for VSCode is in the works so I'm hopeful for the future.
To give you an example of what you can do I often use tramp locally to edit files as root: instead of having to fire a different instance of an editor as root to edit a config file I can just do it "remotely" from my main Emacs instance, with all my config and without worrying about messing something up by having the entire editor running privileged.
I work in embedded development so I also often use it to browse and edit files on the live target system (beats using a crappy dumbed down vi from busybox). And of course as you mention for general sysadmin tasks it's also great, I'm a developer but that doesn't mean that I don't have some sysadmin to do from time to time.
My current solution is just SSH/Vim but I think I'd like to go back to a graphical editor. I like Vim but sometimes it's a hassle on the big projects.
How many files are you able to handle, remotely, with Nuclide/Watchman?
Does it work if the remote files are on an NFS share (i.e. spotty inotify/fanotify support) mounted onto the server you're SSHing into (no, the NFS share cannot be mounted directly on the workstation)?
How many file-change events (on your workstation or on the remote) can this system successfully sync/handle in a short time? If there is, say, a 250k file alteration that happens due to checking out a branch, is there an indication that it detected the changes and is making progress syncing them, or does that necessitate a manual sync?
Context: I've worked in environments where local editing and manual sync got really annoying: for compliance/regulatory reasons, certain tools, e.g. source control, were only available on the remote server, so having all code on my laptop and manually syncing to the remote got quite tedious. Even better, the significant (i.e. I might conceivably need to open them/run tests that touch them) number of source files in the remote repo was in the tens of millions. I wasn't able to get any incremental sync/change-detection systems working successfully: on my workstation (OSX), large changes would overflow the fsnotify kqueue, no matter what wrapper around it I used. On the remote, watching was either unavailable (due to the age of the Linux server) or prone to failures in the event of large changes in files (e.g. checking out a new branch).
I've spent a lot of time mucking about with lsyncd, unison, and lots of other tools, and eventually gave up with the conclusion that directory-diffing is too slow given slow remote filesystems, and change notification systems aren't up to the task of managing bulk changes across a huge repo. Watchman sounds really promising here; I'd love to hear more about your experiences with it.
However, things don't work as well with an NFS share and I think you get an explicit warning when you try to do it.
One of the steps is to install Watchman. If your remote server is on Linux, make sure to read that part of the docs: http://facebook.github.io/watchman/docs/install.html#linux-i... (In my case I just set the three settings to 999999)
Finally, you may need to create a .watchmanconfig file at the root of the folder you're working on.
Also, the manual is pretty good. It comes with Emacs, of course, or can be read at https://www.gnu.org/software/tramp/
My favorite thing about TRAMP is how well integrated it is. It's not just opening remote files, you can also open shells on remote systems, or do file management with dired (I have a bookmark pointing to dired on a remote system I use frequently, for example.)