The problem is that this encourages lazy development. Many developers love the ability of tools like Tomcat that allow you to run your web app inside of the application server itself, rather than having to configure a pesky Apache server.
The problem this creates is that once a developer has it running on their own machine inside Tomcat (or now this PHP built-in webserver) the app is probably coded in such a way that it will ONLY run inside this server, and will never scale. What's more, they often turn it into a production application with real customers depending on it, and blame you if you can't make it scale to handle hundreds or thousands of users.
This is the problem with using "built in" webservers. It encourages developer laziness, and encourages people to kick bad code over the fence to the operations team who has to make it reliable and run in production. Never mind that a built in PHP webserver will never scale to meet the needs of more than a few users.
Sounds more like a procedural issue being created by poor programmers and bad management. Not testing it on a production-like environment is a capital offense whether you are using a development server or apache/lighttpd/nginx.
I think it's better if the devs run something close to the production environment.
The problem is, web developers already have a lot on their plate.
LAMP. The operating system, the web server, the database, and the scripting language. Plus HTML, Javascript, and CSS. And all the frameworks that "simplify" making these work together nicely. Then they have to figure out how to deploy on the test and prod servers. Oh, and they better back everything up. And some redundancy would be good.
Not to mention having some domain knowledge. The above is fine for a to-do list, but they might also need to know how to solve "real" problems, not just do IT.
"I think it's better if the devs run something close to the production environment."
I used to think so too, but I changed my mind a few years ago. Have diversity in the environment in the phases leading up to staging/testing leads to many problems being uncovered early - hardcoded paths, platform assumptions, potential performance issues that only show under some circumstances, ...
I think it improves the code if various devs use different installation paths, DB's, development tools and even OS's. I've seen many deployment issues that would have trivially been detected if devs had different environments.
While I take your point, the major factor at play here isn't what webserver you are using for development it is the fact that you (as the developer) are the only one hitting the server.
> the app is probably coded in such a way that it will ONLY run inside this server
Isn't this exactly what developers are currently doing? A lot of projects are heavily relying on .htaccess files and having the webserver do redirects/pretty URLs for them. They're putting part of the application logic in the webserver...
PHP in general encourages a whole lot worse things than lazy development. If we've already agreed to overlook it's other shortcomings by saying "good developers matter, the programming language doesn't" then we can overlook this too.
The problem this creates is that once a developer has it running on their own machine inside Tomcat (or now this PHP built-in webserver) the app is probably coded in such a way that it will ONLY run inside this server, and will never scale. What's more, they often turn it into a production application with real customers depending on it, and blame you if you can't make it scale to handle hundreds or thousands of users.
This is the problem with using "built in" webservers. It encourages developer laziness, and encourages people to kick bad code over the fence to the operations team who has to make it reliable and run in production. Never mind that a built in PHP webserver will never scale to meet the needs of more than a few users.