Exactly. As long as it fits your situation, it's fast enough. My last company used Ruby a lot (and it's what got me hired there), but we hit so many cases where the data was so large that we were forced to use something else. My colleague would fall back to Java, but I used those times as excuses to learn Go.
Where Ruby fits, it's wonderful. Where it just doesn't fit, all of its niceness is overshadowed by its scaling issues.
I've done massive (billions of rows) ETL jobs in pure ruby (since 2.2.0) without Ruby being the bottleneck. A lot of performance problems I've seen went away when they fixed the garbage collection (especially of symbols). There's a small handful of others I saw resolved by using JRuby.
I mean, if you need good threads, you probably shouldn't be on Ruby, but as far as I can tell its single-core performance is pretty okay compared to other scripting languages.
It's still the absolute best (most features I need in the standard library, or easy to use libraries, and easiest to use) thing I've ever used for working with manipulating large quantities of text (save for maybe Perl, but ew). I've started using Elixir when I need concurrency, but Ruby is still the language I'm most likely to use for most classes of problem.
Where Ruby fits, it's wonderful. Where it just doesn't fit, all of its niceness is overshadowed by its scaling issues.