I feel like CGI Perl scripts back in the late 90s was definitely a critical reason for me picking up on programming, web dev (as a high school kid), and eventually becoming a professional web developer, and software engineer.
The whole web dev paradigm back then starting from basic HTML files, to client JS, to server-side Perl CGI scripts, was just really easy to wrap my head around, and actually create usable products out of. It maps well to a Windows OS file system -- you have these HTML files sitting in folders, you can write them locally and open them locally to see them. Upload to a server via FTP in the exact same structure, and see it work on the internet. If some files are CGI scripts, they run some code on server before output. Input from browser comes in as stdin in the script, and output to browser is just stdout. It was simple enough that as a high school kid, I was able to start one of those "webmaster services" (providing guestbooks, counters, etc.). I have nothing but fond memories building scrappy stuff back in those days.
The only real objective thing I can say about it is that much of the modern ecosystem can have a pretty steep learning curve. Frontend alone, React is quite hard to grasp for a beginner. I'm a Svelte fan and I think it's a lot easier than React, but even then it's no competition to just plain old HTML files and some light JS.
On the backend, now you have this fragmentation in Node, Python, PHP, Ruby, Go, Elixir, etc. In the Matt's Script Archive days, CGI scripts were pretty much only Perl. There were other languages used by some, but they were rare. If you wanted to learn Perl CGI scripts, you pretty much downloaded MSA as well as tons of other free scripts and read them, tweak them, play with them and figured things out. (Not unlike how you simply View Source on frontend to learn HTML and JS)
Bigger sites would use c/c++ and actual shell scripts weren't unheard of either, but that was presuming you actually had an full unix account, which with the arrival of mod_PHP usually werent the case.
Todays deployment pipeline however have gone completely off track with all of the "large team, big cluster" overhead enforced on even small agile part time projects that don't need even 1 full server.
Not OP but things got way to complicated and not much better IMO. Usability has gone down and the number of ecosystems and methodologies has grown and continues to grow at a pace that makes few people want keep up with the latest trend. And things are only accelerating now with wasm. Featurewise the web technology has grown enormously though and one can live inside the browser and get all their needs met but I wonder if this is the direction we really want to take. Living inside the browser is also more distraction prone, not very compatible with the ones who want to do deep work
I started in the early 90s with CGI, I think modern day stuff is really good despite all the complaints. I often think people look back with rose tinted glasses, or remember specific things that were really good while forgetting the general trend of everything at the time. We ( or at least I ) were a lot more forgiving as the new new things enabled stuff we never had before, now expectations are a lot higher.
The whole web dev paradigm back then starting from basic HTML files, to client JS, to server-side Perl CGI scripts, was just really easy to wrap my head around, and actually create usable products out of. It maps well to a Windows OS file system -- you have these HTML files sitting in folders, you can write them locally and open them locally to see them. Upload to a server via FTP in the exact same structure, and see it work on the internet. If some files are CGI scripts, they run some code on server before output. Input from browser comes in as stdin in the script, and output to browser is just stdout. It was simple enough that as a high school kid, I was able to start one of those "webmaster services" (providing guestbooks, counters, etc.). I have nothing but fond memories building scrappy stuff back in those days.