Ofcourse this depends on the kind of project, but my last experience with a big Laravel project was that I was running the project working under Apache on my local machine and the rest of the team was loosing a lot of time because Vagrant was not working as expected.
I can understand the need for reproducible environments. But when so much time is lost I doubt the first thing you need is something like Vagrant.
To me Vagrant is a tool that you use when the team starts to struggle with "works on my machine". But not before that. Because most of the time (well for PHP at least) it's very easy to make it work on all machines.
I've had quite the opposite experience. Vagrant has saved my team lots of time fighting environmental issues. The approach of running apache locally falls apart pretty quickly as you add more components to your application. Elastic search, mongo, one person happens to have php 7 instead of 5.2 and wrote everything with short array syntax, etc.
We also work on many different projects, often getting dropped into something new without much of a primer. Being able to "vagrant up" and not having to know all the dependencies to get up and running is very handy.
Do we spend time troubleshooting vagrant weirdness? For sure, but compared to the time saved it's a no-brainer.
I tend to agree with the parent comment, a small team can get away without it if the software stack is stable. PHP 5.2 to 7 is quite a change and should have been documented upfront. I assume that the project must conform to certain software requirements. On the other hand, npm is full of surprises.
I don't disagree that if you can get away with just a local development environment that it is likely easier to get up and running. However, it requires good documentation of project dependencies and discipline by the team to not accidentally upgrade their version of PHP without telling anyone, both things that are easier said than done. Vagrant lets you codify that through "code". In the case of my employer, it's a necessity, but obviously everyone is different.
By providing your team with the same vagrant environment (usually as simple as committing your Vagrantfile to your repository), then you know everyone is working from the same page and whatever you are building is pretty much portable from one development machine to another.
If you have one dev running MAMP, another running from the default Apple (or Ubuntu/Linux) environment, another running something else, there is no consistency.
We have our vagrant in git and every developer has the same environment. We run on Vbox under Mac OS X. It has been a big time saver and is reliable relative to hosting the dev env natively on mac os x. LAOP stack with the PHP being provided via Zend Server. We connect to a enterprise test instance of oracle.
We are starting to build simple docker containers for python via RHEL SCL version and will have other docker containers to "play" with for a while. Maybe someday we will get rid of Vagrant. Not likely anytime soon.
I can understand the need for reproducible environments. But when so much time is lost I doubt the first thing you need is something like Vagrant. To me Vagrant is a tool that you use when the team starts to struggle with "works on my machine". But not before that. Because most of the time (well for PHP at least) it's very easy to make it work on all machines.