CGI has process-per-request overhead.
CGI typically runs processes as the user the webserver is running as; said processes can generally read and write to the unsandboxed address space of the calling process (such as x.509 private certs).
Just about any app can be (D)DOS'd. That requires less resources with the process-per-request overhead of CGI.
In order to prevent resource exhaustion due to e.g someone benignly hitting reload a bunch of times and thus creating multiple GET requests, applications should enqueue task messages which a limited number of workers retrieve from a (durable) FIFO or priority queue and update the status of.
Websockets may or may not scale better than long-polling for streaming stdout to a client.
I remember doing "custom compiles" for a number of local early web host / Internet providers because their admins didn't want to build C code.