¿Por qué ya no se usa CGI para aplicaciones web?

Todavía se usa, pero no mucho.

CGI fue el primer estándar popular que definió cómo hacer que los binarios en el servidor respondan a las solicitudes web (a través de un servidor web que maneja toda la comunicación HTTP). Muchos de esos fueron escritos en C porque oye, ¿por qué no? La idea de “secuencias de comandos web” no existía cuando se creó CGI; CGI en sí es lo que lo hizo posible.

En su mayoría, lo que reemplazó a CGI fueron los módulos del servidor web Apache que mod_php lenguajes específicos que demostraron ser (o fueron desarrollados para ser) útiles para la web: mod_perl , mod_php , mod_python , etc.

Algunos lenguajes como Java desarrollaron sus propias soluciones completas de servidor.

Un poco de la especificación CGI que todavía se usa en todas partes es el método familiar de pasar parámetros URL, por ejemplo

http://dpaste.com/?title=Quora

Referencia: Interfaz de puerta de enlace común – Wikipedia

Tu pregunta es defectuosa.

Cualquier sitio web que utilice cualquier tipo de script o binario, que se comunique a través de HTTP, que acepte métodos HTTP comunes, como GET, POST, HEAD, PUT, etc.

La mitad de la batalla para hacer que CGI funcione está en el servidor web. Muchos programas con servidores web integrados también utilizarán HTTP. La mayoría de las secuencias de comandos siempre obtienen su información sobre la solicitud directamente de las variables de entorno pasadas a la secuencia de comandos a través del servidor web HTTP. Asi es como ellos trabajan.

Cada script PHP de cara a la web que acepta al menos el método GET es un script CGI.

Es muy costoso (computacionalmente) comenzar un nuevo proceso para satisfacer una solicitud. Los datos útiles no se pueden almacenar en caché en la memoria de proceso entre solicitudes.

Mucha gente se está moviendo hacia una interfaz de usuario minimalista y CGI limpia que realmente contrarresta eso. La gente quiere páginas web rápidas y rápidas que sean mínimas.