Ability to integrate chef or puppet in with VM provisioning is key. Most Vagrant users will tell you they run 'vagrant provision' and occassionally 'vagrant reload' much more often than 'vagrant up' or 'vagrant destroy'. These tasks indicate the real work is not in spinning up/down VMs but 'managing' them after the fact.
To pose a better question (posed by proficient Chef users, anyway) might be why use Vagrant and not knife with the appropriate plugin (will get to virtualbox plugin, in a moment)? For instance, passing argument values stored in a data bag to a knife plugin is (way) more intelligent, flexible and manageable than juggling one giant Vagrantfile. I typically define my 'dynamic' resources like # of CPUs, amount of memory, which OS to deploy, hostname, IP, routes, etc, in chef databag(s) such that I don't need to keep changing my recipe ;-). Editing a databag through Chef web interface is a really easy data entry task I can give to the most junior operators. With Vagrantfile, your forever modiyfing code and believe it or not - code breaks - which pretty much guarantees you'll NOT be handing off simple changes to Operations staff, ever.
Aside from the fact knife does not yet have a plugin for virtualbox (though I envision one in the not too distant future), there are already plugins for most 'enterprise' virtualization products, including vmware, xenserver and just about every major 'cloud' provider, as well. This means knife is far superior to what Vagrant offers if/when you are ready to move beyond virtualbox. For now, Chef community seems happy to let virtualbox users limp along with Vagrant by not integrating virtualbox apis for a knife plugin. There is a knife-vagrant plugin that does allow for use of data bags to pass arguments. But, it still requires vagrant software and it's monolithic Vagrantfile to function.
So, I'll go out on a limb and say Vagrant is definitely NOT 'better' than Chef with knife; but necesary (for now) if you insist on virtualbox and perhaps 'easier' than managing chef with data bags, provided you have a fairly simple environment to manage.
11Two years on I'm now using Vagrant every day for development - it's great! My team uses it and it's solved our dev environment issues. – John Hunt – 2016-02-10T10:04:35.733
1opinionated here: If you never had any trouble setting up PXE servers, know VBoxManage by heart, know how to setup nfs in less than a minute etc. and also like directly managing build chains.. there's close to no point at all. Value goes up with each part of the puzzle you're missing. The widespread use isn't from puppet integration but because people could security-hole infested images right off the internet. no matter what they tell you. – Florian Heigl – 2016-04-16T00:20:55.413
1I also found vagrant far more useful in a multi-developer team whereas previously it was just me. I imposed vagrant on my team and discovered that's where the value comes in. – John Hunt – 2016-05-06T10:53:50.257
23.5 years on and I now use docker every day for development. It's good, but a different beast to vagrant... Depending on your requirements I believe vagrant is still a better development platform for teams - it's just much easier to work with. – John Hunt – 2017-08-18T08:33:16.177
54 years on and I've discovered docker is terrible. Long live Vagrant. – John Hunt – 2018-02-05T15:00:33.003
3your comments are so making this much more fun – Florian Heigl – 2018-02-06T17:44:02.727
15 or 6 years on, I've discovered I have to use docker because everyone else does. The new shiny stuff isn't so shiny in reality.. I don't feel people ever really got to grips with the old stuff yet.. However, it does have its place.. Being able to spin up a quick dev LEMP stack is quite nice – John Hunt – 2019-01-14T10:54:52.107
1Just being able to avoid the enormous amount of wasted space that are VirtualBox snapshots which must be kept inside the VM's directory. – chb – 2019-05-08T04:08:16.537