On the last section, where he says people "weren't avoiding Ruby for speed reasons", that's only true if you take speed very literally. Ruby has concurrency problems compared to many of the more recently popular backend languages like JS, Go, Elixir, or even Java. It has single-threaded performance that's fast enough for a lot of things, but out of the box its ecosystem and standard libraries don't default to evented IO, and the GIL messes up threading, both of which can be footguns for anyone trying to build a resilient and scalable service.

When I was a junior engineer, one of our demos to a client failed because we had a group of 20 people try to use a server that had a highish latency connection to a database, and using synchronous IO meant that a 50ms db round trip for each executed query, with each request running maybe 5 or 10 queries, on a VM with 2 cores and one Rails process per core, would queue up incoming requests until they hit the 20 second mark and started timing out.

Bad concurrency because of evented IO is not exactly the same thing as being slow, but it manifests as much the same developer experience, so it gets misinterpreted and Ruby gets a reputation for being slow.