私の意見では、単一の環境（つまり、C＃/。NET）を使用することの大きな利点は、コードの移植性です。そして、LINQのようなクールなものは、一度慣れると、それなしでは生きていけません。ただし、いくつかのモバイルOS（iOS、Android、WP7）は、UIに関してまったく異なります。
そして、私があなたのアプリケーションについて誤解していなければ、それがモバイルデバイス上で実行される場合、それはUIインタラクションのかなりの部分を持っています。ほとんどのモバイルアプリは80％のUIコードのようなものです。
したがって、いずれにせよ、プラットフォームごとに個別のUIコードのセットを作成することになります。たとえば、Silverlight WP7（およびすべてのWPFの良さ）で作成する場合は、まったく異なるコードのセットを作成することになります。 CocoaのiOS（IB、ビュー、コントローラーなど）の場合、Android用のまったく異なるコードセットを作成することになります。
私の経験では、どのプラットフォームでも優れたUIコードを作成するには多くの経験が必要です。たとえば、WPF / SLの学習はすでに悪夢です。つまり、CocoaTouchとAndroid全体の混乱を招きます。もちろん、見た目も感じもかなり似ている3セットのUIを作成できますが、コードを再利用し、共通のデータ構造を使用しているため、専用アプリと比較した場合、UIは標準以下になる可能性があります。 -そして今日のモバイルアプリのこの斬新な世界では、非スーパー（サブパーは言うまでもなく）UIエクスペリエンスは、アプリの死を意味します。
また、3つのモバイル環境はすべて、マルチメディアパラダイムだけでなく、異なる接続パラダイムも持っています。慣れ親しんだ1つの言語で書いていても、最終的に3つのバージョンを作成し、3つの環境を学習することになります。
再利用するのが最も多いのはバックエンドモジュールです。意思決定エンジン、検索ルーチン、データ管理など。3つの異なるUIパラダイムで動作する3つの異なるUIコードのセットと簡単に統合できるようにするためだけに、データ構造に妥協を強いられるため、これらでも問題が発生します。 。たとえば、MVVMモデルのSilverlightビューにバインドするためにDependencyObjectsを使用していますか？そうした場合、CocoaのMVCモデルでは機能しないため、これらのバインディングを個別にコーディングする必要があります。
また、すべてのモバイル環境ですべての機能を使用できるわけではないため、たとえば、MonoTouch for iOSは、コンパイル時に決定できない汎用構造を備えていません。基本的に、.NETの非常に小さなサブセットを使用しています（そして、どの機能をどこで使用できるかを常に思い出しておく必要があります）。これにより、大きな変更を加えることなく、3つの異なるプラットフォームですべてを実行できます。
.NET機能セット全体をサポートするWP7プラットフォーム用に作成する場合、これらすべての制限があるイメージになります。私はあなたのことを知りませんが、私は夢中になります。また、WP7アプリは、他のアプリとの競争力に近づくことはありません。
私の意見では、痛みと妥協はそれだけの価値はありません。最終的には3つのまあまあのアプリになりますが、どちらのプラットフォームの人も気に入らないでしょう。
すべての長所がアプリのバックエンドロジックにある場合を除き、アプリのバックエンド機能を利用するためだけにUIの問題を無視するほどの長所があります。私の経験では、これはほとんど起こりません。