We currently use a combination of Cequel and the Ruby driver you linked (which Cequel uses under the hood). In our first ScyllaDB/Cassandra project, we assumed that the flexible schemas were more flexible than they actually are (e.g., you can't change keys around without considerations), so Cequel sounded like a good fit. In our second project, which we chose keys and the like very deliberately, we just use the underlying driver semi-directly (we use Cequel::Metal). We handle migrations with a Rake task because migrations don't really work the same as with PostgreSQL (up/down don't make sense in the traditional sense - you don't lose the new columns if you migrate down, you just lose them from new records).
The default answer in the Cassandra community appears to be "run JRuby, use the JDBC driver". Don't do that. JRuby can be great, for the right people, but it's not totally MRI compatible, and it doesn't perform the same. They'll next suggest ODBC. ruby-odbc should be considered a last resort compatibility library. It has a lot of unimplemented ODBC features. It can leak ODBC state and lock up that thread, or crash the process(!) if the driver doesn't guard against poor thread safety. It will perform exceptionally poorly in Rails. Don't go that route either.
These two suggestions are about all you get, at least from when I looked around. It would appear that within the Cassandra community, a lot of people are still applying 10 years ago Ruby impressions to modern Ruby. By that, I mean they assume that JRuby is faster than MRI due to the JVM, because Twitter dropped Rails and switched to the JVM. This isn't really the case anymore (and hasn't been in some time). There are some situations where JRuby excels, but plenty where MRI beats it. The folks recommending JDBC probably have good intentions, but it feels a lot like "your language sucks, use ours". This attitude seems to cause them to spend time doing e.g., Python or Go drivers, but not Ruby drivers.
If ScyllaDB were paying me to work on a driver, I would take their C/C++ driver and use FFI to wrap it and expose a decent API. I would probably not write an ActiveRecord driver because I don't use ScyllaDB/Cassandra for our primary data objects, and non-key-based queries (the main reason you'd use ActiveRecord) aren't possible without WITH FILTERING, which you probably do not want to make available to HTTP clients. You can use materialized views and all that, but then the query is slightly different. A library on top of this could map these concepts to ActiveRecord. The hard part with a FFI wrapper will be to thoughtfully design an idiomatic interface; the rest is thankfully pretty easy due to the FFI project's efforts.
