Are servlets really necessary in the core? Yes, they may have been central to Java EE for as long as Java EE has existed, but things are changing, systems can no longer be seen is a big static state store that can just be queried and updated with synchronous communication, rather they are being build using streams, where the current state is in a constant state of converging, but never actually getting there, and communication is primarily asynchronous. Look at things like Kafka Streams and AWS Lambda and Azure Event Grid - event based systems that are only concerned with asynchronous messaging are rising rapidly in popularity at the moment. And this isn't even that new, almost 10 years ago Heroku had both web dynos and worker dynos - worker dynos had no HTTP interface, and you could argue that deploying something that started an HTTP server to a worker dyno was overkill. Now is a perfect opportunity to realign Jakarta EE with current industry trends.
And even for technologies that use synchronous communication, look at the rise of things like gRPC - this does use HTTP, but not on top of servlets. No one wants to deploy both a servlet HTTP server and a gRPC server, that's too heavyweight. Other things like gRPC may well surface, do we want the servlet API to get in the way of people using these new technologies with Java EE?
As a counter point against requiring servlets, the MicroProfile messaging spec currently being developed will have no dependence on servlets, and I anticipate that there will be many use cases where you'll deploy services that use nothing but MicroProfile messaging for communication, plus a database.
Perhaps as little as 2 years ago, I would have agreed, servlets are core. But I think there's a big shift at the moment, and a decision to make servlets core today could leave Jakarta EE behind.