ONLY if it's important to you that one process be able to run multiple threads on multiple CPU cores concurrently.

Even without this, there are MANY use cases where multi-threaded concurrent request dispatch makes a LOT of sense. For instance, the recent controversy about heroku routing, right?

With MRI or another interpreter with the GIL, you'd want to run one app process per CPU core -- but having each of those processes also do multi-threaded request handling can still even out latency (that is, avoid those awful ~95th+ percentile latencies in the heroku routing debacle), and increase overall throughput.

Especially if your app, like most but not all web apps, is more I/O bound than CPU bound (waiting on DB, disk, or external APIs).

Any reason ruby still has the GIL and not moved to a thread implementation?

Matz likes the fact that it Just Works and you can't accidentally have weirdness based on how your code runs. There aren't any plans to remove it at this time.

I can imagine a whole bunch of gems suddenly breaking if this changes...

That's true, but I don't buy that argument: look at how fast everyone has updated their gems to be Ruby 2.0 compatible. The Ruby world likes running on the edge; if MRI forced us to consider thread safety, we'd learn about the issue much quicker as a community. Since we'd be forced to. ;)

Oh I don't doubt that the community would move quite quickly to support it, but it certainly wouldn't be without some bumps along the way!

The GIL makes a lot of things in the Ruby interpreter much easier to implement.