Perl's decline was cultural

The documentation for something may not exist, may not be clear, or may just be wrong. Unless you specifically know the answer to a question is laid out clearly in the documentation, blindly telling someone to read the documentation is just being a dismissive asshole.

A much more productive and helpful response is "did you RTFM?" or "check section X of the manual". But those sorts of questions require the desire to not be a dismissive asshole.

The cult of RTFM has always been an impediment to Linux becoming more popular. When I was first learning Linux...almost thirty years ago now...the cult of RTFM nearly put me off the whole endeavor. I was asking for help with "Xwindows" on IRC and the responses were either RTFM (which I had done) or pedant diatribes about "it's X, not Xwindows newbie! It's not micro$oft!" Which was a super fun to deal with. The experience steeled my resolve to at least ask someone if they read the manual before assholishly telling them to do so.

In late 80s and early 90s professional knowledge was way harder to get. Learning required significant devotion, and often was obtainable through experience only, and at the same time computer-related work wasn't as well-paid as it will become later. And had controversial social standing. Like, my brother said "It will hurt your chances with girls, bro!" when I told him I want to be a programmer, and with typical sibling-love added "This, and your ugly face of course".

RTFM emerged naturally with all of these: people paid with their time and social life for this knowledge, and wrote down what they found in manuals, most often for free, and you can't just bother to read them?

FWIW most BOFH types in my memory were C programmers, and early Linux UGs. Perlists in comparison were mild, and way more open (Perl community included biologists, linguists, and other non stereotypically computer people).

Perl decline was to some extent a cultural thing. But absolutely not the culture the author means. In Perl Larry Wall promoted a sort of expressive style of writing code where you can chose between several compiler-equivalent ways to implement logic: There is More Than One Way To Do It (aka Tim Toady) principle. The alleged reason is that the choice you make conveys some subtle nuances of your thinking which 1) gives you more comfort while coding, 2) gives potentially more information to someone who will read your code. This was outrageously contrary to the mainstream tendency of commoditization of software development (and software developers) which started to gain the steam at those times. Managers wanted (and I guess still want though to the date the idea mostly failed) THE one and only right way to code each task, peferrably with the only one language (with Java as the main contender), standard training programs, and certifications - all across all domains, and as a result replaceable and transferrable coders. Perl was clearly unfit for this perfect future with its proud selection of 4 or 5 implementations of OOP, and it hurt the language promotion a lot. And then there was disastrously optimistic declaration about soon-to-be major uprgade to Perl 6 which in reality will take 15+ years, all while lots of interesting things happening outside.

Perl wasn't arcane on purpose, the bar for being a programmer was just that much higher, born through necessity as we didn't have as much material to easily turn someone into a capable engineer, so to make anything work you had to -really- be motivated to learn, and that extended to the entire skill tree of things that happen before learning to code, like simply navigating the machine and being able to reach the realization that you needed to write something on your own.

Perl evolved to suit the needs of those that used it at the time, and it reflected their interests, skills, and abilities.

These days everything is so abstracted, so available, so easy, all of the material to learn literally anything is free and at your fingertips, programmers don't need to be that knowledgeable to identify a need and generate some code that mostly addresses that need.

Or did the language itself just get outdated and replaced? (there's nothing wrong with that! most things don't last forever!)