Earlier quoted context omitted.
I don't particularly want to be involved with a long lived and non trivial collection of Ruby code either, if my experience of the Gitlab codebase is anything to go by. I agree with the author's point, if you replace Ruby with something less awful (Deno, Go, etc.)
This feels like the exception that proves the rule. Gitlab has one of the largest Rails codebases on earth. It's also been built by a decentralized remote engineering org from the start. I think that explains a lot. Compare that to my personal experiences and that of my colleagues who work heavily with Rails: We show up to a new job at any level of seniority, spend a week or two learning the codebase, and immediately…
Some of the older stuff built around rails overdid the meta-programming. Makes unraveling things a little more difficult, but you generally know where to look.
And every time I see a nontrivial state machine using a state machine gem, I know I’m in for a world of hurt. But I know exactly what mistakes I will be fixing. :)