Paweł Świątkowski thank you for your thoughtful comment.
Indeed some features will not work, or they are a bit experimental or they are covering some corner/edge cases.
And it is true that I would not recommend to use them in production without discovering how they work, if they fit or not a certain way.
My hypothesis is that unused features means we have no data to assert if they are good or not.
Thus even if in the past there might have been some disappointments, we should still try to use new features so that we know how they behave. Maybe we should start use them in smaller projects first or side projects and explore and write about how we learn more data about them.
I also agree it is kind of a vicious circle with adopting new features: we don't use them because the libraries are not using them or because we don't see them in production code thus we don't use them in our production code either so someone needs to start first :)
I agree a lot with your statements that Ruby used to push boundaries more and that it became too conservative (while hiding behind empty statements like "it's good that it's boring).
But on the other hand, we have features like Guilds/Ractors, that promised solving most pressing issues with GIL and concurrency, but their implementation is half-baked at best, they are slow, not reliable, don't work with Rails (the latter might not be language's fault, but still).
I can kind of understand why people are not very trigger-happy to try out new things in their production code, given the bad history of releasing new things with Ruby in past few years. And this is the only way to wide adoption. Libraries can't do it, because they usually target older versions of the language as well.