1) Nearly everybody but you is an idiot, and the rise of Python and Ruby to take over several problem domain formerly dominated by Perl (and having better penetration than Perl in problem domains where other languages, like PHP, are more dominant) is entirely capricious and due to whimsy.
2) You're not understanding something as well as everybody else, most probably the particular problem all those people using Python/Ruby instead of a Perl as their language.
What's more probable, do you think?
PHP began life as the antithesis of "goto considered harmful." The idea to embed a language directly into a mix of HTML/CSS/JS was just profoundly awful. Yet we still bash "goto" as the spaghetti monster. I guess we just can't detect irony today.
To your #1 point, I'm going to have to say there are a large number of powerful, well-funded, well-marketed idiots in this industry. If languages really mattered, we would all be using Scheme, ML, or Haskell or something. People are just now discovering Erlang, thanks to WhatsApp and Facebook. Despite Erlang being a year older than Perl. But Perl didn't make recent headlines for a $19bn sale, so...
Tail call elimination is more about allowing a particular style than anything else. Python encourages a different style, so why should Guido care about tail call elimination?
Most people I have encountered who have chosen a language have done it in a seemingly arbitrary fashion, so no, I don't believe either of your statements.
I used to not like Perl because of having to touch other people's "ascii puke", but I've gotten past that and still think of it as the best language for manipulating text that I've used.
YMMV
People don't need to be particularly stupid to be driven by trends that aren't entirely founded on reason. And preferences can be both subjective and valid.
I don't have a dog in this particular fight (while I worked in Perl for at least five years, I stopped over 10 years ago and moved on), but I think it's pretty much a reasonable claim that Ruby and Python and Perl (and maybe even PHP) are all more or less in the same class in terms of capability. Python and Ruby may have some gains at certain margins (perhaps Python in particular with the focus on clarity in both the language and community), loses in others.
I could try and weasel out, and I kinda will, because that's a bit stronger than I think my argument really is, which is that if something is popular, it is likely to be better. (Well, that's not the entirety of my argument, I'll come back to that for a second.)
When you assert the strong form, like you just did, the argument becomes exceedingly silly, because rephrasing almost ANYTHING short of mathematical formulas or laws of physics as a Universal Truth makes it at least somewhat silly. But when you look at it as a probability rather than as an absolute, yes, you should expect more popular things to be better than less popular things, no? Not necessarily even overwhelmingly so, but more often than not, right? And quite often, when you scratch an argument for why something that has lost (rather than some new innovation) is better than the thing that became popular, often what you find underneath is a mismatch between what the arguer thinks is better and what the people who chose the popular thing think is better. And maybe they're wrong about what's better, or maybe they were right about what was better given certain constraints that Moore's Law or the cloud or whatever has made irrelevant and now they're persisting due to network effects or whatever.
But to go back to the original poster, who's a Perl programmer trying to figure out what to do with himself. I think writing off the popularity of languages that followed Perl as being due to fadishness, rather than actually investigating why people chose to develop new languages, learn them and build tools for them, is putting an obstacle between yourself and learning new things. You may learn that people had bad reasons, or that they had good reasons at the time but you can do something better than what they had to choose from then. But you'll learn new things, rather than closing yourself off to them by writing off new things that replace what you know best as "fads" and people who adopt them as driven by something other than merits.
It's sort of the liberal flip-side of Chesterton's fence -- Chesterton says that you shouldn't tear down a fence until you can understand why it was built, i.e. you shouldn't change something unless you understand it. The converse is that if everyone keeps tearing down a fence, you should understand why before you put the fence back up again.
You may be responding to something that isn't in the article at all.
I first learned Ruby in 2000, mostly because Dave and Andy sent me a copy of the just-published Pickaxe book. There were few reasons to use Ruby in the English-speaking world back then, unless you were a language magpie or had very simple needs and didn't already have a scripting language in your toolkit.
I didn't do much with it until 2004, when Dave told me to check out the nascent Rails. (I'd already failed to convince my employer to cover Ruby in more detail even though many of the clever and insightful people I knew had started to pay attention.) We published the first Rails article anyway, and it was a good thing we did.
Even then, I didn't use Rails seriously myself because it and Ruby offered no benefits and only drawbacks. It was slower and had fewer libraries and worse tools than what I was already using. (Unlike a lot of Rails adopters, I wasn't primarily working in either J2EE or PHP.)
In 2014, even with Ruby and Rails off of their 2007 peaks, the metrics have changed a little bit. Ruby and Rails have better job prospects, in my experience, while the tooling and ecosystem and languages themselves are roughly equivalent. (One's better in some aspects and the other is better in others.)
Funny thing, though. It seems like around here Rails or Django are the old guard--the conservative technologies no one will lift an eyebrow at you using--and things like single-page client applications served by Node.js are the exciting technologies with new libraries and frameworks announced every week.
Some of those will succeed. Some will fail. Given that I'm not 14 or 19 or 22 anymore, that I spend my days working hard to deliver value for clients and/or employers, and that I have other things to do on nights and weekends than sit in front of a computer, where do I focus my time and energy and resources so that I can both get things done well now and continue to be employable for the next fifteen or twenty or thirty years?
That is what the article was about, not calling everything but Perl a fad.
Why is Node.js popular now? Because people want to create web applications that are responsive without requiring the client to constantly poll the server to see if there's new data, and Node.js does that better than existing tools.
Why are NoSQL databases popular now? Because right now, it's a lot cheaper to scale up by buying more computers than it is to scale up by buying better computers, and current relational databases are bad at scaling up that way (compared to other parts of the stack). Now, I think that NoSQL sometimes throws out the baby with the bathwater, and I do think there are cargo cult NoSQL users who are convinced that if they go around throwing out babies they'll eventually get some dirty bathwater. But NoSQL does solve real problems, and (to the point here) those are problems that are really difficult to predict that you'll need to solve from 15 years before now, because you need to know how the economics of buying computer hardware will change in the future.
I don't think it is possible, at this point in the development of these technologies, to future-proof your skills if you want to work on new projects. You can either keep learning the new things, or waiting until other people find out which of the new things are actually going to last and then learn those things. You can use your current skills to maintain legacy systems. Or you can get into something like management, where you can leave specific technical details to other, younger people and focus on broader issues, like relations between your developers and the people they're serving.
Possibly in areas where no serious money is involved, but I haven't experienced this in the big corporate/government world myself. It can occasionally be true, but it's certainly not the rule
A simple example of this would be going with the bloated, more expensive, more error prone product. It may just be that service contracts, existing relationships, available support or even just name recognition (Nobody ever got fired for buying Microsoft...) trump those in some cases.