So, threads and instances are two very different things. They both use memory, though threads use far, far less memory - just like in other languages where you would use threads for concurrency. When Ruby's GIL is waiting on I/O, it allows other threads to do their work. Per the first link, from the author of Puma:
"The reason for that is waiting on IO (talking to a DB, etc) will allow another thread to run"
The threads don't run in parallel, but they do run concurrently. While this isn't the panacea of performance, it does work well with many web apps which tend to be I/O bound (waiting for a database or remote service). So to your original of "Doing a http request or a sql query blocks everything until it finishes. The solution is to spawn many instances" - an HTTP request or SQL query will, in fact, allow other threads to execute while waiting for a response meaning you can rely on threads, rather than instances, and maintain a very low memory footprint.
If you like Ruby but want true multi-threading and parallelism, I'd highly recommend taking a look at JRuby (https://www.jruby.org). Those guys have done an incredible job with it.
Edit: your links show that indeed its blocking and you need to spawn many threads/instances, which use memory.