昨日の記事が予想以上にフィードされているようで、こういう議論が出来ているのをまず嬉しく思います。
もっとも、外で騒いでいるに過ぎないのは確かなのですが、こういう混沌さと真剣さはやっぱり大事なんですよね。
一応言い出しっぺとして、miyagawaさんの記事: [excite Blog の API]に反応しておこうと思います。

概ねこの議論に参加されている方々はmiyagawaさんも含めて(記事でもフォローされているように)ほとんど論点や意見の収束方向に変わりはないように思え、それぞれがそれぞれの記事を読みつつ、納得や理解されているような感じかなと思います。
miyagawaさん記事中のXML-RPCとAtom APIの選択肢に対する考察に関しても、以前ウィザシステムの担当者さんとお話してさせて頂いていたことがあるのですが、私はほぼ同意見です。
miyagawaさんはalternativeな意見とされておられますが、特に私はこれをalternative、少数意見や異論とは感じません。必然的に議論をしていれば単純に出てくる意見でもありますし、論拠もありえます。
ここで指摘されているサービスプロバイダ事情の分析とは、簡単に言ってしまうと既存標準に振り回されるより独自実装の方がコストが安いとの判断が働いたのだろう、との意味と推察します。
# 念のため、文中の「メソッドごとにシグニチャの順番が違っていたりしてかなりうっとうしいことになります。だったら最初からクライアントもサーバも拡張メソッドだけで書いたほうが実装がシンプルになる」の部分がよく理解出来ませんでした。今回の拡張メソッドだとどの程度楽になるかは分かりませんが、XML-RPCを発行してハンドリングする手間は経験則上別に変わらないと思うので。文脈から上記のように理解していますが。
上記に関連して、恐らくtsupoさん記事の

管理画面の html ソースを見たことがある人なら、見覚えがある文字列がいくつかあると思います。 たぶん、管理画面のソース(asp)を元に、XML-RPC API を作ったんでしょう。

という指摘が鋭く思え、内部的には管理画面とフィールド名を合致させてやることで、その後の処理が通常の登録プロセスをそのまま活用できる、といった読みがあったのかも知れませんね。
とすると、miyagawaさんの指摘は非常に現実味があります。
さて、しかしながら(前置き長くてすみません)、これは先の記事でのポイントのつもりなのですが、それでも指摘したいのは、だからこそ何故、実際にシステムに携わるはずの中の人たるエンジニアがそうした安直な方向性へ逃げてしまったんだろうかということです。
私はここに拘っており、サービスプロバイダ側として一括りにしていない、と言えるでしょうか。ひょっとすると、ここがmiyagawaさんから見られた際の違和感がある部分かも知れないし、（そこまで）非難すべきことではないと感じられる差異かも知れません。
「上に言われたから」「コストがなかったから仕方ない」と言われればそれまでですが(もしただ開き直られるだけなら、特に今後これ以上言及するつもりもありませんけど)、単に技術的に無知でやってしまったんなら尚更、上記のような「大人の事情があった」がためなら尚のこと。それが標準 API を実装しないことのデメリットをすでに抱えているのが明白だとしても(しかしながら、晴れて上場企業となったエキサイトが社会における認識度含めて「小人」とは思わないのですが)。
見過して無視をするよりは、議論が出てくる方が明らかに自然だと思いますし、標準無視だと声を上げること「のみ」で非難しすぎ/叩いている、と呼ばれてしまうのはちょっと辛いかな、という気はします。基本的には他の皆さん含めて技術論に徹していると思いますし。
# とは言え、miyagawaさんが提示された視点はこの業界で飯を食っている人間なら必ず陥るジレンマである訳で(こんな納期とコストでやらされたら、何人か首吊るっす・・)、非常によく分かっているつもりではあるんです。
一点、現状では全くこうした事情の真実は何も知らない訳で、今後標準に即した実装が計画されていて正式なアナウンスが出てくるかも知れないのは確かです。
正直に言うと私なんかはかなり軽く考えていて、実は今日あたりエキサイトにメールで軽く聞いてみようかな、などと考えていたのですが、先方にしてみればそんなおおげさに騒いだり見つけたりして欲しくない(例えば今回の対応はやむを得ない一時対応で、とか)のかも知れず、もうしばらく傍観してみようかなと思います。
「しばらく」の定義は難しいですが、いずれにせよ様々な目や声、時間が経てば先入観に変化した視点に晒されることになるのは明白でしょうし、それこそが実質標準プロセスの根底なのでしょうから。
取り留めない文章で失礼しました。