I very much agree with most of what you have said. The developer community is big and growing everyday, and, what's more important, it's difficult for people to just leave what they were using to embrace a new technology just because it does stuff better. I've seen people running MSDOS applications, which they keep tweaking, just because they decided to create them 30 years ago. People keep designing new games for the Amstrad and, probably, even the MSX machines. In part, anything that's difficult enough is a challenge, and gives you street cred. On the other hand, I found jarring something you said in your article. 700 pull requests is a lot of pull requests. Even if people worry about that particular code, it's kind of clear there's no one on the other side vetting and reviewing those PRs. Those PRs address some particular concerns, mean something is not working (or not working correctly) for someone. Most of those people one stale PR away from abandoning that technology, and moving on to Elixir or Go. At the end of the day, technologies don't die, but they get a bit sick and are finally used in small, and slowly decreasing, niches. If they are not taught in workshops, if there's no vibrant user group, if there are no new tutorials, if the new basic technologies are not embedded in them, well, they will eventually stop being widely used, and they will become the next COBOL.
I've been starting to find that the term 'niches' is a major weasel-word in its own right: it's usually used to claim that the technology is used by "that little group over there," as a way of dismissing its relevance. However, it overlooks the fact that virtually all technologies, once past their fad stage, are best suited for a specific use-case. In other words, all technologies are used in "niches". There are no true one-size-fits-all tools in programming.
Also, COBOL has an active community and user group.
P.S. Just glancing, it looks like some of the older PRs on Rails went stale waiting on the author to do something - fix linter errors, merge a branch, whatever. I've noticed that happens a LOT in open source, and it isn't the fault of the project maintainers. However, the entire first page is all stuff from the past week, so that strikes me as active, but not necessarily unhealthy.
I didn't mean niche to be dismissive. I use it in the biological sense, which is kinda close to use case. All technologies are used in niches, and Nature abhors vacuum, so there's a technology for every use case. However, you can use niche or use case or whatever, and it's true that most technologies slowly abandon the mainstream (or the top 20 in rankings, or reach their plateau in number of users with new users balancing those leaving them) and get stuck to a few use cases. You can probably create reactive web sites and even web services with Cobol, but you're better off doing it with, well, Ruby or Elixir. It's very likely that you can leverage multi-core architectures with C, but you'll most likely use Go or Rust, instead of looking for some library or whatever.
And you are true about the PRs. Most of them are addressed, some of them are waiting for OP action. Still, there are a lot that are simply stale, like this one, three months old github.com/rails/rails/pull/33911. And if you see 700 PRs to be merged, you'll think twice (or more) before submitting your own; many people will simply let it go.
There seem to be ~40 devs active in any one month github.com/rails/rails/pulse/monthly, and the balance of opens/closes and PRs proposed/merged is quite healthy, this month. But still, the balance of open - closed is -40 this month. A t this rate, it might take 17 years to clear the PR backlog. That's not unhealthy per se, but it would be interesting to look at past history, and get the number of PRs and monthly contributors... declining numbers do not mean immediate death, it just means that, for many use cases it was used before (say creation of dynamic websites) lots of programmers have moved on and are using something else (say Vue.js, Elixir, or Sinatra). Contribution sustainability is always a problem for fully-volunteer open source projects, and a bunch of use cases are sometimes not enough to maintain a project, not to mention develop it further.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.