This is only true if your framework depends on global variables to manage request state. If your framework passes request state in as an argument to the request handler, then there is no state to reset. Don't use global variables and you don't have any of these problems.
How do you know whether other components (objects, modules) do not keep state between requests? Unless you 1) use language with pure stateless functions like Haskell or 2) delete everything after each request you cannot guarantee that. PHP uses latter approach.
With PHP you can see your program as a pure function whose result depends only on arguments. You don't have to care about memory leaks like you don't have to do memory management when you have a GC. And if you want more performance and less convenience you can always opt into running your own web server.
> Don't use global variables
If you have an object that is persisted between requests you already have some state that is saved.
Programming 101: scope your objects appropriately. If you have an object whose state is bound to the scope of the request handler, initialize it in that context ("don't use global vars" is just a special case of this rule). In other words, everything initialized outside your request handler's scope should have its state reused across requests. The PHP community never entirely learned this, so you guys are building workarounds. This isn't intended to be PHP bashing; just objective criticism.
I do not see how scopes are related to a problem of memory leak. Let's say you have a Django middleware that is initialized outside the scope of a request. Let's say you decided to add some stats counter in that middleware and wrote a code like this:
This code follows your scoping rules but still leaks memory. So it looks like you don't understand why memory leaks occur. I explained somewhere in ancestor comment that to prevent leaks you either need a language with pure functions or reset environment on each request, none of which is possible in Python yet the latter is available for PHP users.
With Django processing model any array can become the source of a memory leak. I have heard that Ruby and NodeJS developers often have to restart their applications every several hours because they even have no tools to find the source of a leak. The problem that does not exist in PHP by design.
You're conflating application state with request state. Updating application state based on a request is a perfectly reasonable thing to do, but it necessarily invites the possibility of a memory (or database, file, etc) leak. Either PHP can't update application state at all or it can and necessarily suffers from the same potential to leak memory (I suspect the latter, since an application without side-effects would be worthless).