Hi, author here. Taking your argument to its logical conclusion we can say that it doesn't matter if your Ruby code is slow
er or fast
er because it's Ruby, we know it's "slow-as-molasses", we only care about developer happiness, and anyways we're I/O-bound, so it doesn't really matter how our code performs...
But in my experience it does. I've built platforms in Ruby that handle north of 1K reqs/sec with bursts of 10K reqs/sec on moderate hardware, without needing to setup a whole cluster of machines that crunch on poorly-performing code.
From my experience, getting the average execution time per render from say 0.1ms to 0.01ms, and especially reducing allocations and GC pressure has a big effect on 99% percentiles, and consequently on the cost of compute.
Saying because we use Ruby we don't care if it's slow or not is in a way dismissing it as a viable platform for writing reliable software (because performance is part of reliability).
To me, you can use Ruby to create systems that have very good performance characteristics, and still benefit from developer happiness. The two are not contradictory.