I think we live in different worlds, and that's a bit PHP's problem, many of it's devs and users do.
From my pov, manually logging in on a server has been something for emergencies only for a long time now (10y+), and if it's frequently required or even essential to deploy and run an application, this is a sign of bad practices. So the last thing I want to read to deploy some software is "can literally be copied and pasted onto another machine". Maybe you can do that, but you never ever should even have to consider doing this. Where is your versioning, ci/cd (testing, quality gates, automated deploy), how do you roll back in case of a problem? How do you track when new versions were deployed? How do you address patching, runtime differences, active PHP modules and php-level config? What webserver do you use, how does it need to be tuned for your workload? PHP-FPM? Do you expect something specific? Do you rely on .htaccess files? The list goes on and on.
These things are a major hassle at the scale I've had to deploy PHP services. Its best option is containerise them, and then you have a bunch of other challenges due to the process per request runtime design impacting monitoring, metrics, autoscaling, ...
Sorry. I wasn't advocating for "copying and pasting", rather, I was using that as an example of how simply PHP can be managed. More generally, the simplest case is often a good proxy for what to expect when dealing with more complex scenarios. Of course we automate the above behind the proper pipelines!
Many of your other concerns are big "nothing burgers". It's not like versioning, patching, config, tuning, monitoring, etc. are any less of a pain in other runtimes. At worst you could argue that it's different.
Because of the separation between PHP and the web server it makes developing PHP really easy because the web server handles the request for you.
But you pay the price when configuring your environment. Apache conf, php.ini, php modules, htaccess, etc.
To avoid too much craziness I tend to avoid custom htaccess files, unusual php modules, or weird php.ini settings to minimize the friction when deploying.
For large project you are almost required to run containers, but even then you can’t escape the custom bash script.
From my pov, manually logging in on a server has been something for emergencies only for a long time now (10y+), and if it's frequently required or even essential to deploy and run an application, this is a sign of bad practices. So the last thing I want to read to deploy some software is "can literally be copied and pasted onto another machine". Maybe you can do that, but you never ever should even have to consider doing this. Where is your versioning, ci/cd (testing, quality gates, automated deploy), how do you roll back in case of a problem? How do you track when new versions were deployed? How do you address patching, runtime differences, active PHP modules and php-level config? What webserver do you use, how does it need to be tuned for your workload? PHP-FPM? Do you expect something specific? Do you rely on .htaccess files? The list goes on and on.
These things are a major hassle at the scale I've had to deploy PHP services. Its best option is containerise them, and then you have a bunch of other challenges due to the process per request runtime design impacting monitoring, metrics, autoscaling, ...