The entire Yeoman ecosystem will probably seem like "overtooling" then :)
WordPress is simple, yes, but a distributed team workflow with complex tools with WordPress is extremely difficult without these tools.
Here are the problems we've had without these tools:
- Our large WordPress sites existed on the single, live server. Installing plugins, uploading themes, fixing bugs, etc. always carried a huge risk, especially when something breaks but you wouldn't know until caching cleared.
- Every developer (out of a team of ~12), to work on the site, had their own LAMP/MAMP setup, some using WordPressMU, none using Vagrant, and many struggling to get a copy of the database & import it (which is difficult for a lot of WP devs).
- Because of the complexity in setting up & deployment, building semi-complex applications on top of WP was incredibly difficult, mainly because of lack of consistency between environments
- The staging environments that we did have were still out of date, and had a different .htaccess with basic auth for (pseudo) privacy. This got modified, erased, or erroneously "deployed" to production countless times. Not to mention issues with Google indexing a preview server for our distributed team.
Now this "overtooling" should make a lot more sense :)
For example, migrating a site between two servers can now be done by any member of the tech team with a couple of commands, and without worry!
I think you're ignoring the usefulness of both being able to start a project immediately and being able to have a portable development environment.
"Wordpress runs out of the box everywhere PHP/MySQL is available." So.. when devs work on multiple projects with different requirements, different configurations or even different versions, nevermind the mess of using the same database server for multiple projects or of splitting one LAMP stack.
It just works.. until it doesn't, and then you need those "overtools".
> IMHO WP is not complex enough to have a necessity to develop with it in Vagrant.
I develop static websites in vagrant boxes. Why? I don't want to have any spillover from my development env to the host env. I have no webserver running on the host env, only the system ruby installed, no homebrew, no php other than what came with the box, no database, nothing. Everything I do goes into a containerized env that I can just delete when I'm done. No version conflicts between multiple versions of the same database, no leftovers after cleanup. Once you started working with vagrant boxes and have an appropriate workflow it's just less hassle to spin up a box than not.
If you're deploying a personal blog, sure. What if you want to create a web service to automatically provision and deploy WP servers? There's a purpose for every 'overtooled' bundle of software, otherwise it wouldn't exist.
Let's make a science out of running something simple as a Wordpress that runs out of the box everywhere where PHP/MySQL is available.