Yeah sure, no need for state in a CRUD API. But while it is the most common use case for PHP applications (well actually for application written in scripting languages working with http servers), it's not the only use case.
When the only place where you can put state is the database then every piece of state is written in the database. Which lead to intelligent individuals (no pun/offense intended) to write clever piece of infra such as Redis. The truth is, for 10 Redis deployment there's 7 (8? 6? Well, a substantial part) where a long living process holding little state would have done the trick. Now you need to deploy, maintain and scale Redis too.
Yeah, but having to use Redis is a must for any web app/API that grows. So all PHP is doing here is forcing you to adhere to best practices of shared-nothing architectures early on.
Session variables are tied to user sessions (like name suggests), so they cannot be used to persist application state (e.g. cached content, compiled templates, metrics, etc.)
I see downvotes on my GP post, I'm simply stating the fact: if you need state for a building a powerful webapp then obviously there's better runtimes that PHP+Apache, I don't see how one could disagree with that statement, apart from not having sufficient experience in that matter.
There's plenty of good reasons to counterbalance that fact thought, PHP has a very good ecosystem, multiple mature/powerful web frameworks, and cheap/abundant workforce. But it lacks a state holding runtime and for the most demanding applications it's a sufficiently big technical hassle to encourage seeking other runtime and/or language.
