RightScaleには向き不向きがあると思います。
例えばインフラエンジニアにとっては、もどかしい管理ツールだと思います。
逆に、インフラエンジニアがいないけど、今すぐサーバーを用意しなくてはいけない（そしてお金もある）という人には向いていると思います。
なぜRightScaleがもどかしい管理ツールなのか？
それは、RightScaleをよく理解しないと、RightScript単体がこける理由が分からず、実際の起動に至るのに何度も試行錯誤しないければいけないからです。
RightScriptは並び順に実行され、個々のScriptが成功値を返さないと、次のScriptが実行されません。
確かに色んな機能を兼ね備え簡単に使えると歌っているServerTemplateは沢山あります。
でもそのServerTemplateと、RightScript、そして入力（input)がどのように関連ついているか理解しないと大体ハマります。 つまり、InputからRightScriptを読むはめになるのです。
通常は
ServerTemplate = RightScript + Inputですが、よく理解する為には、Input --> RightScript --> ServerTemplateを読み解いていかなければいけません。
一つ一つのRightScriptが何の為に存在するのか、実際にどういう動きをするのかをコードを読んで理解しないと、エラーになった時に対処が出来ない。
RightScriptを書いた人が、どんな考えを持ってそのコードを書いたのかを理解しないと、Inputも正しく理解出来ない。
公開されているServerTemplateを組み合わせてサーバ構成を組む場合は、それぞれを理解しないと希望の構成が出来るかどうか念入りに検証しなければいけない。インフラエンジニアならば気になる所だし、気にすべき所ですよね。
バックアップ取れます！と言っているけど本当に取れるか、ちゃんと検証しないと有事に取れてない事が分かっても困る。
使ってもいい予算も限られているだろうし、質の保証もしないといけないし。
インフラエンジニアの性として、環境を最大限に活用する、というのがあるんじゃないかと個人的な経験から思います。サーバを増やしたり、メモリを増やしたりで解決するかもしれないけど、まずは色んな設定をチューニングして、効果を検証する。
だからRightScaleがチューニングした設定やScriptはコードを読んで、検証したくなると思うんです。
だからRightScriptを含めて、RightScaleをよく理解するしかない。
もしその時間がないならば、安くはないお金を払ってRightScaleに希望の構成を作ってもらう、もしくはアドバイスを貰うのが一番いいんだと思います。そしてそれを（お金を払ったんだからちゃんと設定してくれている、と）信じる。
それしかないと思います。
RightScriptを読んでいくうちに、つい思ってしまいます。
『これ、自分で（コマンド打って）構築した方が早くね？』
でもクラウドの利点を最大限に使う為には、クラウドの欠点（落ちる可能性が少なからずある）も受け入れなければいけないし、そもそも１人で二桁のサーバを手動で構築するのはやっぱり大変だし、クラウド管理ツールを使わずに質の保証をするのは難しいのが現実です。
脱線したけど、RightScaleはお金で買えるクラウド専用SEで、もし自分がインフラエンジニアだとしたら、RightScaleとお友達になる以外により良く使える方法は無い、という事なんだと思いました。
そして一度仲良くなってしまったら、ベンダーロックインされてしまう、というのもありますね。ふー、悩ましい。
（RightScaleで作った構成を他の管理ツールが引き継げる事は出来るのだろうか？）
後付けたしですが、管理ツールがアメリカにあるから、レスポンスが遅い。IPを見て最寄りもAWSに飛ばしてくれたらいいのになーと思います |ω・。）ﾁﾗｯ
追記：欠点というよりRightScaleはOSSじゃないから、OSS的な事を期待するなら、自分で開発してコード公開する方が気分的にいいのかもしれません。
2011/10/24: タイトル変えました。