It's a little more tightly coupled than just a file system; it's essentially a fully headless mode.

Tightly coupled is often not desirable.

the VSCode SSH extension runs the editing process remotely so it doesn't need to transfer the entire file.

It's not really clear that that would be faster... sshfs would load the file once (maybe slow, but it's usually a tiny text file) and then do all editing locally in memory. If the editing process is remote, every edit you make is going to involve round trips over the network? That sounds awful?

If you're doing C++ in VSCode the C++ extension will use ripgrep to index your project. When using sshfs, rg runs on the local machine, causing sshfs to load your entire project which if it's large can really slow you down.

The VSCode remote extension installs extensions onto a VSCode remote client installed on the remote machine. So the C++ extensions spawns rg processes on the remote which is a lot faster.

Maybe but folks have been using vim/ssh since the days of vi/telnet. It’s not a problem under normal conditions.

Its closer to vi over ssh.

That could be helpful, text files are often tiny though.

sshfs (and samba for that matter, even more so) can cause odd kernel behavior and crashes, unfortunately. They're great when network is 100% perfect, if you never suspend laptops, etc. If any of those assumptions go away, you've got a mess.

>odd kernel behavior and crashes

I was under the impression that sshfs is based on FUSE, which works in userspace.

It is. That doesn't prevent bugs in FUSE itself.