現在私がお世話になっています部署では，ＶＢによるコーディングが幅を利かせております。この事自体は構わないのですが，特に近年では，ＶＢによる機能的な制限が非常に緩和されてきたためもあり，以前にも増して「とにかくＶＢで作る」という風潮にあります。
しかもこれが工数削減に貢献していればともかく，実際には「ＶＢを使っているが故に」工数が増大している部分が少なからずあります。（例えば，ＡＰＩを直接呼び出す部分）
それにも増して，特にこのところ「ＶＣを使えない人かいるから，ＶＢでやる」というのが多くなってきているように感じており，この点において非常に危機感を持っております。
特に，Windowsでの開発だけなら良いですが，将来的にサーバーサイドがLinuxになったりすると，私の部門で開発をする場合に非常に困った事態になってしまいます。
私の部署では，表形式のコントロールに，文化オリエントさんの「Spread-OCX」をよく使用しているのですが，とりあえず現時点で（個人的に）一番ネックとなっているのが，このコントロールの存在です。このコントロールは，ＶＢ以外のプラットフォームでの動作保証をしていないので，このコントロールの存在意義を薄めることが第一です。
幸い近年のＵＩ上の要求で，Spread-OCXの機能では（かなりのコードを書かなければ）実現できないような仕様も増えてきておりますので，Spread-OCXより高機能のグリッド表示コントロールがあり，ＶＣでも使用することが可能であれば，ＶＢで作る根拠の一つが無くなります。何か言われた時に，「それはSpread-OCXではできませんが，こっちのコントロールだとできるんで，こっちに変えましょう。」とやるわけです。
個人的には，Professional
DB Sheet なんかは，データバインド・表示機能共にSpread-OCXよりは高いと思いますが，現実問題としてはＰＧの慣れが必要になる事でしょうか。安定性については，いくつか採用事例があるようですので，そんなに心配はしていませんが。
あとは，カスタマイズの面からすれば，ソースコードが公開されている，HyperGear/Gridはかなり有効でしょう。
前述の通り，ＶＣあるいはＣ言語のレベル時点からのスキルを持つ者が少ない状況では，ＶＣでコンパイルが通るような基礎知識を付けるまでに，かなりの総工数がかかります。理想を言えば，開発量の小さいプロジェクトでかつスケジュールに余裕のあるプロジェクトを餌食にする方が，会社にとってのダメージが小さいのでよいのですが，いままでの仕事の振られ方からして，このような状況は見込み薄です。
どうせやるなら，一番リスクの少ない状況下で決行したいと思うのですが…。
とりあえず，少しでも怪しいようなＵＩ仕様が出てきた場合には，「これはＶＢでは無理ですね」といって，ＶＣでの開発に持って行くように心がけます。
あとは，事前に，まず出てくるだろうという要求に対して，「こうこうこういう要求が出てくるとＶＢではできないんで，今のうちからＶＣでやっとく方が早いんですが，そんなことはないですよね？とか何とか言って，設計側に圧力をかけるのも手です。
もちろん何か変更を要求された場合は，「だから言ったじゃないですかぁ！最初からＶＣでやってたらすぐに対応できるのに…ブツブツ」とやるわけですな。で，いそいそとＶＣで作り直すと。
ＶＣが，ＶＢに比べて劣っているところには，大きく次の３点だと思います。
逆に，ＶＣがＶＢと比較して勝っているところは，次の５点だと思います。
ＶＢの場合，自モジュール以外との通信は，基本的にＣＯＭベースを強制されます。従って，フロントエンドだけならともかく，大規模システムをＶＢでやる場合，基本的にはＣＯＭの概要を知っておく必要があると私は考えています。別の所でも述べていますが，（設計はともかく）いやでもオブジェクト指向での実装を要求されることになります。計算主体・ファイル操作主体の場合であってもです。実際に，Visual Basicマガジンをご覧になってください。ＣＯＭ関連の記事が，紙面のどれだけに充てられているでしょうか？
一方，ＶＣでやる場合には，ＵＩ部分はＭＦＣやＡＴＬを使うことが現実的とはいえ，必ずしもオブジェクト指向でやる必要はありません。計算主体の処理ではなおさらそうです。このオブジェクト指向での開発能力を要求しないという点は，ＶＣを使うことのアドバンテージになります。
この点を引き合いに出して，「ＣＯＭの勉強とＣ言語の勉強とどちらを選択させますか？」と要求してみるのも手かな？と思ってます。
Unicodeでは，シフトＪＩＳコードでは区別されている似たような字（特にマイナーな旧字や異体字）は，同じ文字コードにされています。これはUnicodeとシフトＪＩＳとの関係は，１対１ではなくＮ対１ということです。従って，シフトＪＩＳ->Unicode->シフトＪＩＳという変換を行うと，変換前後で文字が化ける事があり得ます。具体的な文字を挙げられなくて申し訳ないですが，このレベルまでの字体の厳密さが必要なシステムでは，Unicode処理を避ける必要があります。
ところがＶＢでは，常に処理をUnicodeで行います。従って，このような文字化けが発生すると困るようであれば，ＶＢは言語仕様上使えません。。
もちろん実際には，このことを理由にすると使えなくなるのはＶＢだけではなく，ＣＯＭベースのツール全て（Spread-OCXしかり，Oracle Objects for OLEしかり）使えないということになりますし，ＪＡＶＡも使えなくなります。さらには，ファイルシステム内の文字（ＶＦＡＴのロングネーム部分とＮＴＦＳ）もUnicodeですので，名前を直接ファイル名などにする事もできなくなります。もちろん，この理由を盾にする場合は，これらのことをおくびにも出さないようにする必要があるでしょう。
一番良いのは，MDI親ウインドウがEXE，MDI子ウインドウがDLLとか，ドッキングウインドウだらけといったような構成で，へろっと決めてしまうことです。これはＶＢでは絶対できませんので，全ＵＩの設計し直しか，泣く泣く（笑）ＶＣで作るかの選択に持って行くようにしむけます。極悪です。
あと過去の実績としては，プログレスバーの経過表示があります。これは，モーダルダイアログの表示中に，モードレスダイアログを表示する処理を必要としますので，少なくともライブラリ化する場合はＶＣで作らざるを得ません。
あといままでしっかりやっていなかった部分では，マウスカーソル形状の変更（特に砂時計マーク）があります。ＶＢでのマウスカーソルの制御は，自モジュールが持っていないフォームの上にマウスカーソルがある場合には制御できません。従ってＤＬＬからマウスカーソルを制御しても，実用上はほとんど無駄です。このような仕様をしっかり入れておいて，何か言われたら「それは，ＶＢでは言語仕様上できません」といって，ＶＢ化を防ぎます。
他にも，ＶＢ一色の開発からの脱却のため，あらゆる方策を求めております。有効な方策がございましたら，こちらまで。