Your question is why we have http servers and http middleware at all. Running an application directly on an endpoint makes sense for embedded application, but for everything else you will end up with a separate http terminating layer for a number of reasons.

It makes maintenance so much easier, when you can scale request backends independently of request frontends. It makes sense that the application doesn't have access to TLS keys and can't bind end user facing ports directly. The day you want a separate access log from the application log, and separate instrumentation of the frontends because of some hard to track down bug you will be thankful it is there.

So, you want to deploy some sort of proxy. Will you run FastCGI, SGI, WSGI, uWSGI, plain http, or a number of proprietary load balancer protocols? If you choose http you have to take care to wash your headers and be very careful with pipelining so front and back end expect the same behaviour (which is true for several of the proprietary protocols too). Otherwise there can be catastrophic security implications.

It is probably true that FastCGI was designed as a persistent CGI. But as soon as you have persistence, the http server needs to forward transactions to the persistent backend, and what you have built is a proxy. There is no way around it.