Also, these technologies are generally designed to solve some problem, and get adoption because it's a common problem. Struggling with a solved problem rather than using that new tool that solves it is upsetting.
Let's take web templating: How many solutions are out there, and how many of those actually turned out to be winners? To ride the crest of the React wave, you had to pick it out of a thousand others, at a time when there were other "winning" solutions.
And even React is beginning to show signs of falling, with new stars starting to shine. Do you jump ship, or hold the course?
For an existing project, the bias is to not change unless the new language gives you a massive improvement. Re-writing is always harder than you expect, because the existing code base has more bug fixes and handled corner cases than you think it does, and your re-write has to preserve all of that (or suffer the consequences of failing to do so).
The wisest time for a dev to learn a new technology is probably at the peak of its popularity. That way, you learn from the community when it's most active, and your expertise grows more valuable as the technology slowly goes out of style. Like the author, this happened to me when I first picked up Rails in 2008-2009. I jumped on board at a time when everyone was talking about it, so I never had to look hard to find information. For the next 5 years or so, it seemed like my job prospects were getting better and better, even though the hype train had left Rails behind shortly after.
I have a pet theory that a lot of the shiny-toy syndrome we see in web development is actually fueled by startup founders who deliberately choose unproven technologies to attract talented developers ("Join us, we actually use language XYZ in production!"), since programming geniuses are often eager to delve into Turing tar-pits, and also dazzle tech journalists by promoting it as their magical secret ingredient. (...and yes, I'm aware that perhaps Rails rose to popularity this way)