I recall a discussion where Let's Encrypt engineers stated they were unhappy with the notBefore/notAfter spec from RFC8555, because that gives the CA absolutely no leeway to align timestamps:
The server MUST return an error if it cannot fulfill the request as
specified, and it MUST NOT issue a certificate with contents other
than those requested.
Meaning that if an ACME client submits dates in the notBefore/notAfter fields, the CA is not allowed to
- backdate the notBefore
- round the lifetime to a sensible number of seconds, if the client specified something weird
- clamp the lifetime
A spec-conforming CA has to instead reject the entire order, which isn't great. Let's Encrypt has had some compliance nightmare around the lifetime of certificates and as such would like to avoid too much variability around the lifetime of a cert. This isn't possible with the current specification, unless you reject all orders that do not exactly match the lifetime the CA expects, or you intentionally violate the specification.
Let's Encrypt would instead like to have the duration CA-controlled, not user-controlled, to avoid potential issues around lifetimes as much as possible. This just doesn't work with user-specified dates. Therefore, it's not that likely that LE will ever implement notBefore/notAfter as per RFC8555.
Also, the ACME profiles extension allows for much more than just adjusting certificate lifetimes. It allows the client to specify a preference for various other things: The CN field has been deprecated for a long time now, and Let's Encrypt would eventually like to get rid of it, without breaking workflows that depend on it. Profiles are a way for users/clients to indicate readiness for such changes, such that the CA knows if it can safely use newer standards.