Currently my development environment is Ubuntu v12.04 with VMWare. I work entirely inside of the VM, with full GUI and only use samba file sharing within Ubuntu if I need to get to the files from my host OS which is Windows 7. I normally access and map a network drive via the internal IP of the VM via NAT for networking to the VM. Using other solutions proved to be much slower like VMWare's Shared Folders. I have this disabled in my VMWare Image settings. I do however install VMWare tools to allow for easy copy/pasta to my host machine and vise versa.
As Matthias Zeis pointed out, be careful in your selection of networking/shared folders with your VM as some will prove problematic.
I was previous user of VirtualBox but found VMWare to be more stable and performs acceptably (at least for me). I would however perform your own tests to best suit your needs and requirements, ie. Vagrant uses VirtualBox.
I was using Netbeans quite extensively as my IDE of choice but have since moved to a more lightweight solution as Sublime Text 2. I rarely will open Netbeans as mainly for X-Debug purposes and easier Refactoring. Netbeans, PHPStorm, Eclipse, etc. are all Java based IDE's and can be very resource hungry.
To add more, Hardware will always be a key role in performance (obviously). If your developers are still using platter HDD I would look to invest in SSD for them. Since Magento has a very large amount of files/folders it will greatly speed up developers performance. While developing: With all caching off, and While simply traversing the folder tree in SVN/GIT, or your IDE. Giving your VM enough RAM is also just as important.
My Host Machine:
Samsung SSD 512GB Drive space, Win7 (64bit), 8GB RAM, i7 2.4GHz (8 cores)
My VM Machine:
Samsung SSD, 30GB Drive space, Ubuntu 12.04 (32bit), 3GB RAM, i7 (4 cores allocated).
QUESTIONS TO ASK:
The biggest question is, to create one Developer VM Image that is lightweight and reusable across multiple projects, or to create an Image per project. Previously I was trying to do smaller VMs on a per project basis however the reconfiguring constantly to go with my development workflow became too much of a chore, and now use one larger VM and try my best to keep each project as isolated as possible.
Maintaining OS, IDE, LAMP Stack, updates/configurations, etc. can become a chore if multiple VM's per project is the route chosen. Ultimately leading to longer development time (and even worse un-billable time for local environment setups).
This has also proved helpful, as I was quickly able to access other project files without the need to open up a new VM and slice my Host hardware even more. The downside is ideally I would want each project to be siloed from other projects to prevent any unforeseen issues with the environment (ie. php.ini, my.cnf, httpd.conf, etc.). So far the tradeoff of having all projects easily accessible has proved to more resourceful.
Again this is up to your requirements and needs so evaluate them before hand.
Which leads to feedback. Get as much input from your developers as possible. Ultimately their requirements need to be met and their problems understood before a proper solution can be set up and put into place. Everyone has different workflows, and not everyone is comfortable working in the OS you may chose for development. My rule of thumb is let the developer chose their OS and IDE they are most comfortable in and will perform best with. So even a lightweight headless linux VM may prove useful to their needs, but obviously can run into the issue of sharing the folders across the local network between the Host and VM.
I have also toyed with the idea of keeping my VM Image on something like Dropbox so I could easily access it at any time I may need. Since services like Dropbox compare bit by bit of what's stored it seemed logical that only the bits i've changed would be synced. However this proved not to be the case as I believe it has to do with the internals of how the Image file is saved, and I would be waiting all day/night just for my VM to sync.
The larger the drive space allocated to the VM the larger the Image will become, keep this in mind when distributing the Image to your developers. Front loading your project files per project may be overkill and I would leave this to each developer to set up after they have the created image.
Ashley Schroder has a somewhat old related article that is a good read, as well as some of the comments by Fooman and Colin
Hopefully this helps with insight to your listed item of problem, #6.