How to hold back from interfering with students' inefficient-but-not-wrong work?
What if you were to write up a list of "general development tips"? Then you can share it with everybody once instead of constantly giving unsolicited advice.
You can also then give it to future students and hopefully get them started off well from Day 1.
Does your research group have weekly meetings? If so, you could devote 5-10 minutes at the beginning of each meeting to workflow/development hacks that you think would be helpful. If your group does not have periodic meetings, it may be worth implementing some even just solely for this purpose. Students may not like this at first, but the net productivity increase will be beneficial to everyone. Also, you won't have to point out individual inefficiencies to multiple students (at least not as often).
I implement something similar when I teach, but this is more geared towards undergraduate stuff. I discuss things like how/where to apply for scholarships and internships, tips for getting into grad school, navigating workplace politics, and also some simple workflow things from time to time. Students have commented that this has been very beneficial.
I like @Nate Eldredge's idea of coming up with a list of general development tips, but I think this alone might have some shortcomings. It may be time-consuming to write up something really high quality that covers everything. Some students may not even read it (but these students probably won't pay attention to anything you say during a meeting either). Other students might not understand your suggestions until they see it in practice. This actually happened to me the other day. I knew of Emacs' Tramp, but never understood how to implement it. I saw a tweet with an animated .gif demonstrating how it worked, and I've been using it everyday since. Perhaps discussing these things in meetings and building a list of development tips over time may work well.
You could also make some group requirements that make your life easier. For example, you could require that your group use Dropbox (or something similar) to share documents, and in the process that may encourage them to use it for their own material. (You could keep the development tips document in a shared folder on Dropbox as a start!) I do think pointing out inefficiencies in person could be worthwhile, but you definitely would have to pick your battles and only do this from time to time.
EDIT
Some of the comments indicated that the several of the OP's recommendations are "objectively wrong," but I think that this misses the point. If a more senior researcher sees ways that her/his group could be more efficient, these are likely worth sharing even without possessing the perfect workflow. Sharing code through Dropbox may not be the best solution, but it'd certainly be better than emailing files back and forth. (I'm not even sure the OP was suggesting that the group share code on Dropbox; this is just an example). Also, it's possible that the students may have suggestions for the group (or even group leader), and these could be fleshed out by gathering everyone together.
One comment also suggested not getting into a Vim/Emacs holy war... but do the students know about Vim, Emacs, other editors/IDEs, and their capabilities in the first place? I certainly didn't know about these as a Master's student, and developing skills with an editor would have helped me tremendously (I'm not in a STEM field, so these tools are uncommon; I'm not sure about the OP's field, but again, this is just an example). You could definitely discuss features and capabilities without getting into a holy war. Mere exposure might be tremendously beneficial.
My approach would be much more subtle compared to João's method. Instead of out right telling them what to do, I would show them my workflow while answering a similar question. Make sure to do this on your own computer, do not 'drive' on someone else's PC.
An example would be to show them your "development method", with a large code window. Use shortcuts or the CLI while they're watching what you're doing. You can say something like "foobar saves me a lot of time", but not too much. The students which want the higher efficiency in their workflow will naturally pick up what works for them.
"You can lead a horse to water, but you can't make them drink"