私は主として組込み関連の開発に携わることが多いのですが、それでもWindowsのデスクトップアプリケーションを作成する機会もそれなりにあります。
そして多くの場合、高速な演算など、ネイティブコードを書くことになります。

GUIの開発は、Windowsに限ればC#が何といっても便利です。
そこで、ネイティブコードの部分はCやC++で記述して、C++/CLIを間に入れるかどうかはともかく、C#でフロントエンドを作るのがこれまでのスタイルでした。

ところが、C#とC++を混在させるときにはいつも面倒な問題が立ちはだかります。
そもそもプロジェクトの構成管理が面倒ということもありますが、何より面倒なのはちょっと複雑なデータ構造の扱いです。

内部処理に有利なように、データ構造はネイティブコードで扱いたいのです。
けれども、それだと直接UIでデータ構造にアクセスすることができません。
もちろん、そうした問題を回避するためにグルーコードを書くのですが、面倒ですし、パフォーマンスの低下にもつながります。

あるいは、UIで使い慣れたprintf系の書式を使えないといった問題もあります。
ネイティブコードでできたサードパーティ製のライブラリも使いたいのですが、C#から呼び出すのは何かと面倒です。

いろいろ考えた結果、もしかするとこれが最善の解決策ではないかと思えるアイデアにたどり着きました。

C#からCやC++で書いたDLLを呼び出そうとするから問題なのであって、すべてC++/CLIで書いてしまえば、上記の問題はほぼすべてが解決します。
WPFを扱うにはC++/CLIではさすがに不便ですが、Windows Formsであれば何の問題もありません、

最近のVisual Studioは、新規プロジェクトの作成時にC++/CLIによるWindows Formsアプリケーションのスケルトンを生成してくれなくなりました。
けれども、そんなものは自分で好きなように空白のプロジェクトから作ればいいし、その方が余計な方をはめられずに済むので快適です。

そして、必要ならC++/CLIからC#で書いたDLLを呼び出すのはいとも簡単にできてしまいます。
逆の面倒さとは対照的です。

他のプラットドームへの移植性を考えると、UIと内部処理はうまく分離するのが望ましいといえます。
C#でUI、C++で内部処理というのはわかりやすい構造ですが、いろいろ面倒なこと、うまくいかないことも少なくありませんでした。

けれども、C++/CLIでUI、CまたはC++で内部処理とすることで、そうしたわずらわしさからは解放されます。
C++/CLIからはC++のコードをシームレスに利用できますが、そうはいってもUIと内部処理を分離するには十分な壁が存在するのです。

今後は、CまたはC++で内部処理を開発し、フロントエンドにはC++/CLIかMFC、UWPならC++/CXを使う体制を築けたらと考えています。
LinuxなどではQtかwxWidgets、あるいは簡単ものならTcl/Tkをフロントエンドにするとよいでしょう。