I don't think that's the case at all. The problem is exactly the same in any language - which is why we've seen a multitude of Java / Perl / Python / Ruby / C drivers developed to do the exact same thing.
As someone has already pointed out, it's not about the threading, it's about turning a blocking request, into an asynchronous one. (Deferring work until you have the data to perform meaningful actions with it).
I think the reason this is a bad idea is that in order to turn a blocking operation into an async one, you're adding a totally new transport layer (HTTP) and data representation (JSON), as well as middleware. That means a significant performance hit, and a lot of needless complexity (and potential for failure).
It would be much simpler to either make the database driver itself non-blocking (Postgres' client library supports async queries, for instance), or use a dedicated pool of threads to perform blocking DB operations. It might be that Ruby's threading is too broken for the latter to be feasible, but it still makes using DBSlayer just to get async DB operations needless overkill.
As someone has already pointed out, it's not about the threading, it's about turning a blocking request, into an asynchronous one. (Deferring work until you have the data to perform meaningful actions with it).