This kind of query comes up a lot.
Allow me to try to help with some of your questions/issues.
Developer's should have their own environment to develop and play around
This is certainly possible, and is actually quite common. Your restriction would mainly be the license agreement that has been arranged between you (the customer) and SDL. If your license agreement does not include provision of developer licenses, then that's a different problem.
With respect to your Tridion experienced friend, 3 weeks to set up a CM and CD environment is far too long. For example, I created a basic environment last week and it took me around 2 hours.
You state that a VM is not a neat solution, but I would beg to differ. I routinely run Virtual Machines with varying configurations and customer specific customisations. Tridion requires some significant resources to operate, including SQL Server or Oracle, so it's nice to be able to shut all that down as a whole. Running Tridion in a virtual machine does not in any way prevent me from developing templates and extension code locally, which I can compile and deploy to my VMs quickly and easily once I understand the process. Having a VM also means that I can take advantage of snapshots to roll back to previous states of configuration.
Code (including DWT) should be subject to source control
Tridion versioning != code source control. You should, of course, have all of your code (including DWTs if you deem it necessary) version in an SCM system. Tridion does not prevent you from doing so. I think it's fair to say that versioning in Tridion is mainly for content versioning, but it just so happens to work for some other item types.
Developers should be able to merge changes to a common system seamlessly
This is another reason why you should use a source control tool for your code. I have seen customers setting up continuous integration for templating code as well as DWTs, so it is possible.
It should allow to preview and publish code for tridion (and custom) code.
I'm not 100% clear on your question here. There's a great slide in Content Delivery training that I always emphasise when I am giving it... "Tridion does not run your website". Unlike some CMS systems where they both manage and deliver your content, Tridion typically manages content and then publishes it to a data store somewhere (either on disc or into a database, depending on your needs). This means that you can consume this content in 100s of different ways! The Content Manager will show you, via template builder and/or it's preview functionality, what it writes out to your content data store, but it can't show you what your application is then going to do with that output. This doesn't mean that you can't preview though... In my current project, for example, all content is retrieved from a database and processed by a web application. All of the developers can run their code locally and see instantly the results of their changes before committing it to their SCM tool, which then builds and deploys it out to an integration testing server. The editors can use Tridion's Experience Manager interface to edit content in-line on the actual staging web site and then see how those changes will look via the Session Preview feature before actually publishing it.
To summarise, Tridion works differently to many CMS systems that you may be more familiar with. It is very powerful, flexible and it doesn't make too many assumptions about how you want to manage or deliver your content (and code!). Remember though, "with great power comes great responsibility"... Tridion requires you to understand and utilise it's features well to get the best results, but in return it will reward you with an extremely well tailored and customised experience for your organisation.
