aI have been working for the past 4 years in variations of the environment you described. Here is my experience with them:
Local environment (http server installed locally + other systems)
Although it is arguably possible to deploy the environment in all OS, the reality is that you will face with a lot of problems regaring different configurations, available modules, library versions... It means that lots of developers will work on his very own environment, different among them and different from production environment.
This setup is very nice with the developer: it is very fast, he obtains knowledge about the whole picture, very useful for trying new configurations or alternative software. If the developer has some sysadmin skills, he can fix configuration options, change the enviroment so some specific feature is easy to develop or test...
As the code and development tools are also local, daily work is very fast.
Local VM (dev environment in a VM, running locally)
You will need to create a dev virtual machine and send it to your developers. Also, you need to provide updates (probably as another VM), but some developers will not install it if they have customized their personal VMs too much. You also need some kind of global configuration, while still allowing particular settings for each developer. But then you will face the problem of developers tunning their VMs so much that it becames to different from production.
The developer needs a very powerfull machine, specially for web development. Nowadays I'm using a dev VM, a windows VM (to test things in IE browsers, for example) and the dev environment. My dual core and 8Gb of RAM can't handle that nicely, is a real mental pain to work with that setup.
There are three alternatives about code:
Code is local, deployed to the VM to run it: Working with local development tools is very fast. Although most tools have automated deploy options, in my experience they didn't work very well when you need to work in the other way (update local code with VM code). . Works better using a SSH connection for particular tasks (i.e. global searchs)
Code is in the VM, shared with local development tools using some remote-acces solution (samba, sftp...): Depending on the developer SO or personal setup, it might not work very well. Potentially you will face problems about permissions, polluted directories (aka Thumbs.db and .DS_Store everywhere) and random disconnections. Some tools features (like indexing or global searchs) will be very slow. Works better using a SSH connection for particular tasks (i.e. global searchs)
Code is in the VM, the developer works using server tools through a remote shell. Good solution if your developers like this setup and you can find a good replacement for each local softare used by your team (very unlikely, specially for designers)
Remote Environment (dev environment is in another machine)
This setup is the easiest to to maintain, as new configuration options or software just need to be deployed in one place. With a good server you can host up to 50 developers, so the worst case for mid-sized companies will be to maintain 3 or 4 development servers.
You will face privileges and security problems: some of the developers might need root access to do their job, so they will be able to change the environment, potentially breaking it and stopping the whole team (or worse, losing the in-progress code). As the number of developer grows this will become a serious risk. In my experience, in a machine shared by 20 developers expect a broken environment at least once per month.
Obviously, it has network dependency: if the developer does not have network access, he can't work. You will need a VPN setup to provide access to out-of-office developers, access to remote clients or testers, access to dev environment from your sales people outside the office... Security becomes more important than ever.
For code, very much like Local VM setup, plus adding networking issues. Expect frustrating slowdowns and random disconnections.
Remote VM (dev environment is in a VM, running in a remote machine)
Pretty much like Remote Environment setup, but you can scale it better. On the other hand, you get the problems of deploying the dev environment to too much different machines, so chances of differences among them and production environment are higher.
My personal choice
Use LocalVM and local code. Speed in every day task is very important if you don't want to make your team angry, so local code is important. Most tools works fine for remote deploying, and any "advanced" developer using the reverse way (vm->local) probably can figure out how to do that nicely by himself.
Invest money in powerful machines for the team so the machine speed is not a stopper for anyone. A remote cluster of VMs or a auxiliary and cheap laptop can be very helpful for developers working with heavy development tools.
Obviously you're not going to get a definite answer here, because it really depends on your individual case and, in particular, who's working on the project. I'm not sure what you intend to gain though, but it sounds like you would have to throw away a lot of work.
Scala is slightly more buzzword-compliant these days, but Python is no slouch when it comes to functional programming either. Still, it all depends on the specifics of your workload.
Just remember Knuth's advice about premature optimization; he's a pretty bright guy. I'd say if you're even remotely close to finishing, then don't change. It's far more important to get some working code as quickly as possible than to "do it right" the first time. Because you simply don't know what you will have done wrong until you can test it.
Then, once you know what your choke points are, design something that addresses your real concerns.
Best Answer
I've worked in multiple projects in a similar environment to what you describe. In my experience something like this works pretty well:
To address some of your problems...
At least with SQL databases it's relatively simple to keep the database shared. You can just take dumps of the data and copy it over to the other people.
You don't necessarily need to have the same exact data on all developer's computers. It should be enough they can perform testing etc. with the data they do have.
The testing/staging server should preferably have the same data as your production server - this is to ensure your code gets tested in a realistic environment before it's moved to production.