Funny. I completely disagree, and actually find it odd someone actually wants desktop style application state on web apps. One of the beauties of the PHP style of app execution is that application state is a lot simpler. Instead of having a running application server-side, which can be in a continuum of states, PHP forces you to start every request with a blank slate. Application state must be explicit (with serialized server-side sessions or browser-stored cookies). This makes it trivial to reproduce requests, trivial to debug, trivial to scale horizontally.
To each his own, I guess. I just find your position genuinely surprising.
By starting every request from a clean slate, you have much less mental overhead (did I accidentally reuse a variable from a previous request?) and it eliminates an entire class of programming bugs. It's the best thing about PHP, and despite this approach PHP still runs faster than many similar languages.
I think the "clean slate" benefit is achievable almost for free in a monolith though - each request is a separate invocation of a handler function which is given the context it needs to run (e.g. an HTTP request, an output stream and user-defined context).
The user-defined context is the only route into the application state and can be as wide or narrow as you need. So you can share persistent state deliberately, e.g. by having that context contain a pointer to a db conn, but this is always a conscious, opt-in choice, and errors like accidental reuse should be impossible unless you're doing something inadvisable like using global variables.
After doing Java Spring I realized that the Java monolith was very leaky and inflexible. That is why you have strong trend of micro services.
In 99.9% of cases in web development you want the PHP model of doing things. The 0.1% case is the asynchronous background job, that can be solved, maybe not as elegant as in other languages, but why optimize the edge case?
My backend is written in php and I simply have a separate container running a copy of the same php codebase that has a long running process pulling from a pubsub queue in a loop.
So anything that needs to be processed asynchronously, like say, sending out a few dozen emails or notifications, I just publish the task to the queue and that other container handles them.
This could be simplified even further if you use a pubsub service that can post data to a url as it comes in. Thus allowing the single php container to asynchronously process the tasks all in their own individual threads.
This didn't work for me as Google cloud's pubsub seems to absolutely flood it's target with requests seemingly ignoring 503 or any other error code and not backing off until it has dos'ed your server.
The problem lies in your last point. Any PHP+Apache app, no matter how bad the programming practices, has the property that every request gets a blank slate except for explicit database connection. In most other stacks it is way too easy to add a singleton class or a global variable and break that guarantee.
That said, I'll gladly take the guarantees of a type checker in exchange for giving up the guarantees of statelessness. It would be nice if there were a stack that could give me both.
I think it comes down to how we assess the cost of things. To me, the issues you identified with state (which I agree are real issues) are straightforward to overcome with disciplined design. On the other hand, I find not having application-wide state to be a handicap - e.g. I might want to have my application process batch jobs asynchronously or share state between requests in a highly efficient (read: in-memory) way.
Of course there are solutions in PHP-land, e.g. "run a job server" or "use Redis", but I find the overall cost of introducing more programs/services/components to be very high, in terms of learning curve, portability, maintenance and debugging.
I've spent the last few years replacing a crumbly, brittle, temperamental PHP/nodejs/Gearman/Redis/Nginx/Supervisor stack with a Go monolith so I'm sure that influences my opinion :-)
Does that mean you had to re-invent the wheel with your go monolith for a lot of things?
My understanding is that the go philosophy is very package independent and the availability of existing code to solve common problems is rather sparse.
To each his own, I guess. I just find your position genuinely surprising.