掲題の通り、LL言語のGIL (グローバルインタプリタロック）がなぜあるかという話。
なお、以下は全てのLL言語で同様のことが言えるとは限らない、かつ私の認識が誤っている可能性もある、という disclaimer を初めに書いておきます。
（専門家の方々にいいかげんなこと言うな、とか叩かれそうですが、お手柔らかにお願いします・・・）
要はLL言語のランタイム & 標準ライブラリ？ の実装で利用しているライブラリ（ランタイムだったらlibcとか、標準ライブラリだったら、それらが内部で利用している、プラットフォームに存在する各種ライブラリ）の関数がスレッドセーフかどうかいちいち調べて対応する工数がパないからGILで解決してしまえ、って話のようである。
（普及してしまった段階においてGILの必要性について考える場合は、サードの提供するライブラリも考慮しないといけないでしょう）
スレッドの実装が行われた時点で既にそうだったかは分からないですが、例えばPythonやRubyなんかは多様なプラットフォームで動作する実装を提供しているので、合理的な割り切りだとは思います。そんなところではなく、他のところにマンリソースを割くべき、という判断でもあったのでしょう。なので、怠慢だ！とか単純にディスれる話ではないと思っています。
あとは、仮にGILを使わなくて済む実装ができて（少なくともランタイム部分については）、標準ライブラリについても、"スレッドセーフではない可能性があります" とか、ちゃんとドキュメント化できたとしても、サードのライブラリが同様の対応をしてくれると期待するのは難しいだろうし、それが成されたとしても、スレッドを使うときに、利用する関数がいちいちスレッドセーフかどうかとか意識して、コードを書かないといけないというのは、LL言語のポリシー的なところとか、想定される利用者層、用途を踏まえると、ただ使いにくいだけ、になりかねないという判断もあった（ある）のかな、と思います。
ただ、なんかもにょるな、ということが言いたかっただけです。はい。
ちなみに、Rubyで言うと、MRI ( Matzらのリファレンス実装 ) は GIL がありますが、JavaによるRuby実装である JRuby は GILが無いそうです 。あとは、詳しくは知らないですが、 Rubinius という処理系も無いそうです。JRubyなんかは以前から存在を知っていましたが、最近、GILが無いというのを知って、結構衝撃を受けました。
なお、JRuby や Rubinius という GIL の無い実装が存在するからといって、MRI も簡単に GIL を無くせると言っているわけでも、思っているわけでもないです。そこは強調しておきます。
追記:
CやらC++やらだとメモリモデルがちゃんと定められてなくてつらたん、って事情もありそうですね。
https://www.ibm.com/developerworks/jp/java/library/j-jtp02244/index.html
これとは対照的に、CやC++といった言語には明示的なメモリ・モデルはありません。
