One, is that HTTP took over the role of a lot of simple servers, thus something like Apache and CGI-BIN was used in place of inetd.
Second, with the rise of interpreted languages (i.e. Perl et al), forking became more expensive. With binary programs, forking tends to be cheap (in a multi-use case) since the executable page are shared across processes. While the interpreter runtime itself is shared (being compiled), the actual script is not (having to be loaded for each instance).
The HTTP servers managed that better (through modules, FastCGI, etc.), so that space didn't really advance under the guise of inetd.
Make no mistake, an inetd service is "fast enough" for a wide array of use cases today, both compiled and interpreted, simply because the hardware is much better today. But, still, when folks think "ad hoc" service today, they're likely turning to HTTP today anyway.
I don’t recall whether you could tell inetd not to do that.
inetd was (remains?) a perfectly useful solution in this space. It just maybe needs some love to add some convenience features. Off the top of my head: 1) ability to split /etc/inetd.conf into, e.g., /etc/inetd.conf.d; 2) ability to trigger a restart of a specific service, rather than restarting the entirety of inetd.