What is even worse, according to RFC-2616
https://tools.ietf.org/html/rfc2616#section-14.21
date in Expires: can not be in the past. So, here PHP just violates web-standards.

You are misreading the RFC, and even RFC 7234 states it's allowed:

https://tools.ietf.org/html/rfc7234#section-5.3
> An origin server [...] MUST NOT generate an Expires field
  unless its value represents a fixed time in the past (always expired)

which is exactly what we want.

…

Regarding the issue, I doubt it's an actual issue, but I leave that to other people to determine.

"[...]" in your citation is "without a clock". Have you seen many servers with PHP engine and without a clock? Anyway, this combination is not typical.

A typical server with PHP has clock. And it automatically generates the Date: header with current time. The Expires: header with time in the past in this situation is spec violation.

The issue is actual, in particular, because it is unclear, how web-crawlers should treat this situation. Formally, they can treat it as "the page contains outdated content". Therefore, rating of the page can be suppressed.

Check section 4.2:

   If an origin server wishes to force a cache to validate every
   request, it can assign an explicit expiration time in the past to
   indicate that the response is already stale.  Compliant caches will
   normally validate a stale cached response before reusing it for
   subsequent requests (see Section 4.2.4).

That has nothing to do with clockless operation and again says that an explicit expiration date in the past is allowed. Plus RFC section 14.21 doesn't contain the sentence you quoted at all. It doesn't say that the expires date cannot be in the past. The only thing it says is:

   To mark a response as "already expired," an origin server sends an
   Expires date that is equal to the Date header value. (See the rules
   for expiration calculations in section 13.2.4.)

which is not the same as saying it cannot be set to an explicit past value, especially since other parts of the RFC explicitly mentions that it can. If you are going to quote RFCs, please quote them directly and don't paraphrase.

Ok. Thank you for the explanation. It looks like you are right: According to RFC 7234 (not RFC 2616?), PHP does not violate web-standards.

Still, I feel that default behavior of PHP here is counter-intuitive and gives rise to unnecessary questions. Brevity is the soul of wit. And this principle is applicable to generation of headers also. :)