Couple of assumptions here:
1)
The specifications drive the implementations
and they have a one-to-one correlation for any single provider (or one-to-many if we consider multiple providers).
2) Traditionally, app server major versions had direct correlations with Java EE specification versions.
I am suggesting that frequent release versions of Jakarta EE specs should not introduce features that mandate upgrade of Java SE versions as it would not be convenient for consumers to upgrade Java SE versions frequently for reasons stated earlier. Any such feature should be introduced in longer life-cycles which are typical for app servers major versions. The usage of the terms long-term-support(LTS) and feature-release(FR) may be prevalent in product implementations; I am just trying to provide a similar analogy in case of Jakarta EE specifications which would inherently drive the implementations (and versions) of app servers as per assumption #2.
We also need to factor in the various licensing and support pricing models for app servers that would have an impact on consumers. For periodic subscriptions agnostic of app server versions, the regular Jakarta EE/app server FR release versions should not be an issue from cost perspective. But for those who purchased support only for a major version (say, as part of license) this would cause them to renew their license/support subscription more often in the absence of LTS versions.