SQLServerのDTS（データ変換サービス）の変換スクリプトを書くこともできるし、Script Controlを使えばVB/VCからも使えます。

IE5以降ならcscript.exe/wscript.exeがOSに入っているので、これを使ってファイル処理、文字列処理などをJavaScriptの文法で行えます。すばらしいですな。

少なくとも、ActivePerlやRubyを入れるよりはお手軽でしょう。(ASPで使うには多少設定が必要です）
セキュリティホールが多すぎることもあって、IISであるというのが非常に難儀です。この一点をのぞけば、軽さと機能は魅力的なのですが。最近はいまいち分が悪いです。

microsoftのニュースグループ(microsoft.public.scripting.jscript)を見ても、JSとVBSのトラフィックの比率は1:3。しかもJS側ではクライアントサイドの話題も多いので、サーバサイド一辺倒とはいきません。

Netscape Enterprise ServerがサーバサイドJavaScriptをサポートしていますが、これまた大きなムーブメントをなしているとは言いがたいところです。

情報源もきわめて限られている中であえてJScriptを使う理由はあるでしょうか。
そもそも使用言語は、ユーザ要件をのぞけばプログラマが決めてしまって良いことです。JavaやCの経験があって、オブジェクト指向プログラミングに慣れている人なら非常に手になじむ言語になるはずです。（そういう人がASPに手を染めるかどうかは別ですが）
逆にAccessなどでVBAに慣れている人ならVBScriptが無難でしょう。
VBScriptとの比較は次項で述べます。

■できること

• ECMAScript準拠
  要はJavaScriptの文法でプログラムを組めます。C/Javaに近いので、If-End Ifが嫌いな方／中カッコがないと嫌だ！　という方にはいいでしょう。
  Case Sensitiveなのもポイントです。

• 弱い型付け(weak type)
  ASP全般に言えることですが、JScriptは型の弱い言語です。いいかげんな演算を書いても勝手に実行環境が型変換を行ってくれます。
  ただし、型を全く考えずにプログラムができるということではありません。予期しない型変換に悩まされることもあります。

• すべてはオブジェクト
  プリミティブをのぞくあらゆる値はオブジェクトとして扱えます。プリミティブもラッパーオブジェクトを使えばオブジェクトとして扱えます。
  VBScriptではオブジェクト変数を操作するとき、Setを使う必要がありました。JScriptではSetは必要ありません。

  オブジェクトには自由にプロパティやメソッドを追加できます。配列もオブジェクトなので、常に動的に配列要素を追加・削除できます。Redimは必要ありません。

• try-catch/throwによるエラー処理
  もうOn Error Gotoは必要ありません。エレガントなエラー処理をお楽しみください。（ただしfinallyはないのが残念）

• GCによるメモリ管理
  JScriptはGC(Garbage Collection)によるメモリ管理を行います。 ある変数にnullを代入してもただちにメモリが解放されるわけではなく、実行環境があるタイミングでGCを行い、不要になったと判断されたデータを破棄していきます。 ユーザが明示的にGCを実行させることもできますが、推奨はされていません。

• 正規表現を標準装備
  JScriptはバージョン１から正規表現を実装しています。VBScriptではバージョン５からのサポートになりますが、記述のエレガントさからJScriptでの利用をおすすめしたいところ。
  といっても、IE5が世間のスタンダードになった今ではあまり問題になりませんね。 (IE5がインストールされていれば、VBScript/JScriptともにバージョンは５になります）

■できないこと

• メソッドの引数は値渡しが基本。プリミティブ値の参照渡しはできない。
  オブジェクトの場合は参照渡しになります。COMのメソッド呼び出しなどで参照渡しの引数を要求される場合、困ったことになります。

• VB形式の配列(SafeArray)を直接生成・操作できない
  JScriptの配列とは構造が異なるので、直接インデックスを使ってアクセスすることはできません。
  VBArrayオブジェクトを使ってラップするか、toArrayメソッドでJScript配列に変換して使います。また、SafeArrayをJScriptだけで生成する手段はありません。COMを利用すればできますが、やりかたは後述します。

• Nothingを自前で生成する手段がない
  VB/VBScriptではオブジェクト変数を解放するときにNothingを代入しますが、JScriptにはこれに相当する値がありません。nullもundefinedもNothingとは意味が異なります。 JScript以外の手段でNothingを得る手段はありますが、後述します。

• Option Explicitがない
  宣言なしでどんな変数も使えてしまうので、スペルミスはやっかいなエラーの原因になります。
  たとえば、あるオブジェクトの存在しないプロパティを参照しても、エラーにはならずにundefinedが返ってきます。

• Constがない
  気分の問題ですが……

• 引数の省略はできない JScriptでは途中の引数を飛ばすことができません。ある引数以降をすべて省略することは可能です。やはりCOMの呼び出し時に問題になることがあります。

• 文字のascii/Shift-JISコードを調べる手段がない
  VBScriptにはASC関数がありますが、JScriptには同様のメソッドがありません。String.charAt(), charCodeAt()で得られるのはunicode値です。

• パフォーマンスに劣る部分がある
  同じ処理を記述するとしても、オブジェクトのメソッド／プロパティ呼び出しは関数の呼び出しに比べて性能が劣ります。Math.Floor()とFix()を比べると、圧倒的に後者が高速です。
  一般的にはオブジェクトより配列の方がアクセスが早いのですが、JScriptでは配列もオブジェクトなので、速度的なメリットは限定的です。また、VBScriptではResponse.Writeが最適化されています（アーリーバインドされている）が、JScriptではレートバインドのため、低速です。
  逆にJScriptのほうが速い場面というのはあまり思い浮かびません。正規表現や文字列操作では有利らしい（伝聞）ですが。

  限界性能はVBScriptの方が上といえるかも知れません。しかし、もともとASPの性能はwebアプリケーション用プラットフォームの中でも速い方に属します。正しいプログラミングのもとでは、VBScript/JScriptの性能差が問題になることはあまりないでしょう。
  ＃JScriptの文法には、性能差を補ってあまりあるメリットがあると思ってますが。
  IISにおいて極限まで性能を求めるなら、C++とISAPIで作るしかありません。
  

  一般論ですが、プラットフォームの仕掛けを性能順にならべると、こんな感じになります。
  １：webサーバのプロセス内で動作するコンパイル済みコード(ISAPI, NSAPI, Apacheモジュール)
  ２：webサーバのプロセス内で解釈されるスクリプト(ASP, mod_php, mod_perl他)
  ３：cgiとして動作するコンパイル済みプログラム(実行形式ファイル)
  ４：cgiとして動作するスクリプト(perl, ruby, ...)
  servletは１と２の間あたりになるでしょうか。
  

  ASP対応言語の性能差は、以下の通りと言われます。
  VBScript > JScript > PerlScript
  SQLServer 7.0 Enterprise Managerに記述があります。RubyScriptは試してません。
  ベンチマークを後日提供します。

Visual Studio.Netの日本語ベータ２では、まだJScript.NetのIDEサポートがありません。正式版では対応するらしいですが、残念な話です。
国内ではJScript.Netなんて話題にも上りませんね……