Not sure where to put this reply since the thread seems to have split a couple of times, but to clarify my original suggestion.
When I say synchronous communication, I'm not referring to IO. Whether the servlet API is blocking or not is not a consideration to me at least in whether it should be part of the core. Rather, the question is whether synchronous communication - ie, request/response, where both parties in the communication need to be actively participating in the communication for it to succeed, where one party being down leads to the other unable to proceed, synchronous communication is what I don't think should be in the core. The servlet API is inherently synchronous, if a client tries to send a message to a servlet, and the servlet isn't running, is overloaded, or is failing, the servlet won't get that message later when the problem is fixed, this is because it is based on synchronous (dictionary definition "at the same time", ie, both parties active at the same time) communication, whether it's using non blocking IO or not.
The alternative, asynchronous communication, which typically uses message brokers as an intermediary transport, does not require both parties to be participating at the same time, so the sender can send the message regardless of whether the receiver is able to receive it at that time. In a world where deployments now consist of tens, hundreds even thousands of services, requiring all services to be running at the same time, which synchronous communication does, leads to a system that is fragile and far worse than a monolith. Hence, asynchronous communication is imperative in this world of cloud native services.
I'm quite aware that Servlets aren't tied to HTTP, but they are tied to request/response, and this is the issue.
I anticipate that in 5 years, most backend services will primarily just use asynchronous communication - the primary places that will use synchronous communication will be services that directly face users, where users need a timely response to their requests. In many architectures today, this is already the case.
That's not to say Servlets are ever going to go away - it's not an either or, both synchronous and asynchronous communication are needed in all systems. But the current situation, where synchronous is the primary means of communication, reflected by the fact that the servlet spec is in the core, is coming to an end, and it's cloud native that is signalling the end of that. I think a cloud native Jakarta EE is one that treats servlets as an option chosen for the right use cases, not as a default in the core.