Why not FastCGI? It is just another way to connect from the web server to a long running app, just like WSGI is...
Rails deprecated its use 4 years back ( https://github.com/rails/fcgi_handler ), FastCGI is deprecated in Django as well( https://docs.djangoproject.com/en/dev/howto/deployment/ )
common pattern is a reverse proxy to a C based server with or without evented loop with some reverse proxy/load balancer, or some compiled implementation in jvm, golang, beam etc
I am not as familiar with Ruby.
But just because "modern apps and frameworks" don't recommend it doesn't mean it is a bad protocol. PHP with PHP-FPM is awesome and well supported. Fast CGI still has a place in this world, and I don't see why just because some apps/frameworks have decided it isn't worth their time to support it, it would be an invalid choice to make for a new app...
was it a design decision or they chose it as no alternate mechanisms/libraries is available in perl.
these decisions are important to know for a open source project, it will determine its adoption, number of contributors, and will it flourish
This is incorrect. Perl is still seeing good adoption by new developers.
Now your argument could be that it probably not at same rate compared to some of the top languages around at this moment but Perl is still growing.
Some facts...
- CPAN continues to grow - http://cpants.cpanauthors.org/stats/uploads | http://cpants.cpanauthors.org/stats/authors
- According to this tweet Perl still produces more new repos on Github than languages like Scala, Clojure & Go - https://twitter.com/dberkholz/status/395922559151009792
>was it a design decision or they chose it as no alternate mechanisms/libraries is available in perl
No idea what their decision criteria was however they are plenty of alternative mechanisms/libraries in Perl.
See PSGI/Plack for Perl's state of the art solution - http://plackperl.org