アクションとスクリプト、もちろん便利な点と不便な点がそれぞれあるわけです。
　内容と規模で使い分けるのがよいのでしょう。
ちなみに、どちらも給料の査定にはビタイチ影響しないという共通点があります。

スクリプトのデメリットは（Photoshopの場合）
・わからないとどうにもならない
わかりかたがわからない。
・わかるようになるまでやたらかかる
どうにもね。
・わかるようになると周囲から「いい気になってんじゃねえぞ」と思われる
たぶんね。
・わかるようになっても別にモテない
これは…元からモテ要素のある人にはきっとプラスになるんだと思います。
「さっすがー」とか「神は二物を与えたもうてもうた」とか
「あまりの差が付きように嫉妬のしようもないわ」とか言われるんでしょう、たぶん。
モテたい人はイラスターでアピアランスをねちょねちょしましょう。
・スキルを認められると厄介な要求がどんどん集まってくる
それをスルーするスキルも同時に磨いておくとよいでしょうw
・書き上がるまでが遅い
メニュー項目から選ぶだけに較べると、あまりにも手間。途中で心が折れるかも。
・書くだけ書いたあとのデバッグがほぼ必須
書きまちがいを気にしているといつまで経っても書き終わらない。。気がする。
書いて、試して、唸って、捻って、の繰り返しが苦痛な人には向いていません。
・スクリプトではできない処理がけっこうある（ScriptingListenerでなんとなかる場合もあり）
パスのコピペとか、画像操作とか、演算とか。とかとか。
・書いている時、周囲からは遊んでいる風にしか見られない
実はこれが一番困る。
…ほんとは書いている時の顔がニヤニヤしているのに気付いてないだけかも知れない
・使ってもらえない事がある
得体が知れない物は実行の仕方すら覚えたくない、という人も。
これはこれでアリな姿勢ではありますが、
リアルな顔見知り謹製なんだからちょっとぐらい使ってみてほしい(´･ω･`)

ざっとこんなところでしょうか。とにかく手軽さが足りない。
　メリットもかなりありますでございますが。
ハードルの高さを感じている人はたぶん少なくないのでしょう。

対してアクションのデメリットは、というと。
・条件分岐が設定できない。一本道（いっぽんみち）←読みがな蛇足w
条件に合えば処理Aを、合わなければ処理Bを、てのは、基本的にできない。
・処理内容の改変が容易すぎる
コマンドをつまんで順序を変えるだけで簡単に壊すことができます。
また、リスト行頭のチェックを外すだけでその処理をスキップできます。
これをデメリットと捉えるかは人しだい場合しだいですが…
・ボタンモードでエラーが出た時はアクションのリセットが必要
たとえば選択範囲操作系の処理のとき、選択範囲が存在しないとエラーが表示されます。
「続行」できますが、そこまで計算されていないと大概ひどい処理結果となります。
「停止」するとそこで中断します。
このとき、ボタンモードの場合は一度ボタンモードを解除しないとアクションをリセットできません。
リスト上のコマンドを選択できないためです。
ボタンモードをやめて、問題のあったコマンドが選択されているのを解除して、またボタンモード。
めんどーいめんどーい。

新規ドキュメント→保存しないで閉じる　などの無害なアクションを作っておき、
エラー中断の際に実行すればこれは回避はできますが。。
ちなみに、「選択範囲がないから中断した」場合、任意の選択範囲を作成してから
赤いエラー色に染まったままのボタンをまた押してやれば、止まったところの続きから続行可能。
・使いこなせても別にモテない
元からモテ（略
・超絶に極めたとしても履歴書に書いたら鼻で笑われる
書類選考で「もっと他に自慢できる事ないのか」と言われる事うけあい。。
・あまり吹聴しているとActionScriptを書ける人と間違われる
…（笑）

…で、このアクションのデメリットを解消…とは行かないまでも緩和に導いてやろう
　　というのが今回の趣旨です。アクションで済めばスクリプトいらない。
アクション作成は、んまあご存知の通り、記録ボタン押して作業して停止押して完成、なのですが
　ちょっと予防線を張っておくことで、そこそこエラー停止を軽減できます。
ひとつ、その作例でも示してみようかと思いまして。

例として、線画をCMYK変換して指定通り着色したイラスト群があり、
特定の色だけを選択してどうにかしたい、とします。
実際こんなカッチリしたデータを扱う事はあまりないでしょうが。

ところで最近、「おれとカーチャンをオマンジュウみたいにかくな」とクレームがついているので、
ひょっとしたら近い将来キャラの外観が変更されるかも知れません。。
子供は育ちますし。嫁も育ちますし。

いちおう、他の手段では代用できないような処理を想定します。かなりわざとらしいけど。
　２人の体の塗りだけ2pxトラッピングするアクションを記録するとします。
人物以外の絵柄が入ってくることもあり、人物以外は未知の平網で着色されていることにしちゃおう。
　…まその、処理そのものではなくエラー回避についてのエントリなので深く考えないように（懇願

・許容量０でピンポイント色域指定
　　注：Lab値で記録されるので、実行時のカラー設定が記録時と不一致だとコケます
・選択ハニーを変更（拡張2px）
・塗りつぶし（体色：比較（暗））→今回は主線がK100なのでCMY版にだけ作用します
・選択を解除
〜〜２人分の色でくりかえし〜〜
　　…ってなとこでしょうか。もっとラクできるんでしょうか。わかりませんが…

いちおう処理結果。
　ややかぶさってます。

で、複数枚の画像に対しこのアクションでバッチ処理した際、
狙った色のピクセルが存在しないと選択ハニーが作られず、後の処理でエラーが出て止まります。
軽い足取りでトイレから戻ってみるとガックリしちゃうわけ。

そこで、対策。
選択させる色がないなら用意しとけばいいじゃない。

以下の3つのコマンドをアクションに追記します。
・カンバスサイズ…
　基準位置：右上　幅：10px　高さ：空欄　相対：オン　カンバス拡張カラー：ホワイト
・カンバスサイズ…
　基準位置：右上　幅：10px　高さ：空欄　相対：オン　カンバス拡張カラー：その他（体の色１を指定）
・カンバスサイズ…
　基準位置：右上　幅：10px　高さ：空欄　相対：オン　カンバス拡張カラー：その他（体の色２を指定）

この３つを記録したらアクションの先頭にドラッグ移動。
　これで選択ハニーがありません的エラーは回避されます。
　一度目のカンバスサイズ（白）は、2pxのトラッピングにより元のカンバス範囲内に色が入ってしまうのを手前でせき止めて防ぐ、という目論見があります。

最後に、もうひとつ追加します。
・カンバスサイズ…
　基準位置：右上　幅：−30px　高さ：空欄　相対：オン　カンバス拡張カラー：てきとう
これはアクションの末尾に配置。最初に広げたのと同じ分だけ小さくして元のサイズに戻すわけ。

これで吠え面をかく要素はひとつ潰せたわけです。

…といった感じで、
　条件が合えば処理A、合わなければ処理B　というのはなかなか難しいですが、
条件が合えば処理A、合わなければ（結果的に）何もしない
　というフローなら場合によっては可能なわけです。

どなたかの何かしらの参考になれば幸いなんですが…
　続きは反応如何ということで。

でーす。