As pointed out by @Nsukami and briefly summarized in my comment he linked to, this is not supported out-of-the-box yet. But by following these suggestions you should be able to get it to work.
What I don't understand is, if this doesn't work with when ssh'ing into a remote host, when would setting $EDITOR [to anything but emacsclient] by handy?
Using ssh inside of term/shell isn't the only way to connect to a remote and then run a command there. E.g. you could open a remote directory using Tramp and then use async-shell-command. This does work because this does set the default-directory.
This library was written so that Magit could commit using git commit instead of git commit -m message and so that rebasing would work over Tramp - and nothing else. Why one would want that is explained here. That requires the use of the emacsclient but unfortunately that doesn't work over Tramp. So we needed something like emacsclient but which talks back over stdout instead of a socket. The library's header describes how that is done.
Now, when I try crontab -e right after the above, from this same open terminal, I see that it opens a crontab temp file crontab.XXXXzLgfmw on my local Emacs, but it shows me an empty file, even though it shouldn't be empty.
That's because it is a local file, which does not actually exist yet, when Emacs should open a remote file instead. Neither the remote process which needs to use an editor nor the "sleeping editor" process do know that they "are remote" (all processes are local to the machine they run on). Only the elisp part of with-editor (which consumes the sleeping editor's stdout) can know about that and it does so by consulting default-directory.
Tramp does set that variable, so here it just works. term and shell do not do so, but by using the packages mentioned in the emacs.se answer I linked to above, they presumably can be taught to do so.
I will eventually try out these packages myself and if they do their job I will update with-editor's documentation accordingly and make code adjustments if necessary.
But again with-editor was written for Magit, and that doesn't need these features. I was well aware that this library could be useful outside of Magit, that's why I have implemented it as a separate library which does not depend on anything else in Magit. But some of the features it now contains I originally intended for somebody else to implement outside of with-editor.el. @Silex got all exited about the core functionality and so we ended up implementing these things directly in with-editor, but for the time being I don't intend to implement any features not actually required by Magit itself.
running any of those commands hangs up the original terminal
It doesn't actually hang, it just waits for the "sleeping editor" to return, which it does after a week (sic) or when receiving an appropriate signal. Because the elisp part of with-editor, which is responsible for sending that signal, is unaware that it should send it to a remote process, it instead sends it to the local process with the same pid (which hopefully doesn't exist or at least isn't an important one).
