VB2008」で「VB2005」のプロジェクトを開いてみます。

Visual Basic 2005の「仕様改善版」といった印象です。
仕事上の方は「Visual Basic 2008」に移行させました。   開発系の掲示板などを見ていると、未だに「Visual Basic 6.0」ベースの質問もかなりのウェイトを持っています。 VBSVBAなどを併用するような場合には、「Visual Basic 2005」以降は同じ「Visual Basic」であっても記述が大きく異なるわけですから敷居が高いのでしょう。
でも、「Visual Basic.NET(2005以降)」への移行はかなりの勢いで進んでいることは間違いありません。
Visual Basic 6.0」は既にサポートも終了しており、WindowsVista以降のOSでは動作保証もありません。 ClickOnceの恩恵を生かして従来資産を「Visual Basic 2005」に移行させる作業を行なっていましたが、 開発メンバの増強のタイミング(追加ライセンス購入)の段階で全プロダクトを「Visual Basic 2008」に変更させることになりました。
マイクロソフトも動作安定性を謳っていますし、正常進化的なバージョンで「Visual Basic 2005」の開発資産については手を加える必要はありません。 また、将来的に見れば「.NET Framework」の利用バージョンが選択できるとか、「VSTO」が専用エディジョンでなくても利用できるなどの長所もあります。
今回、エンドユーザーにClickOnce環境の提供を行なっている途中で「Visual Basic 2005」から「Visual Basic 2008」に移行させたわけですが、 エンドユーザー側には何の意識をさせることなく移行が行なえています。
Visual Basic 2005」で作成したプロジェクトを開いてみます。
以前に「Visual Basic 2005」で作成した「マルチドキュメントインタフェース(MDI)を作成してみます。」のプロジェクトを開いてみます。
F1_RESULT2のプロジェクトを開く
これは開いた結果ですが、「Visual Basic 2008」で扱える形式に「変換」が行なわれます。 変換の結果は「UpgradeLog.XML」というファイルに出力されるので、これを確認します。
F1_RESULT2の変換結果
このサンプルは、Windowsアプリケーションと複数のクラスライブラリが複合したMDIインタフェースのソリューションですが、 これを含めて、このサイトのサンプル程度のものは問題なく変換されるようです。

実際に実行させてみても、
F1_RESULT2の実行結果
このように問題なく動作しています。

パフォーマンスや安定性についてはどうでしょうか。
今回、「Visual Basic 2005」で作成したプロジェクトを変換した結果では、.NET Frameworkは「3.5」に変換されていました。
.NET Frameworkが「3.5」になった
デフォルトが「3.5」になるということは、特に理由がなければ「3.5を使いなさい」ということなのでしょう。 当然、上位バージョンなのですから、いろいろ改善項目があるのでしょうが、現時点ではその内容は理解できていません。
※上記はExpress Editionでの話であって、製品版では.NET Frameworkのバージョンが勝手に「3.5」になることはなく、従来のバージョンのまま変換されます。 私の会社の状況では、まだWindows2000で動いているPCも残っているため.NET Frameworkは「2.0」で進めざるを得ません。

この程度のサンプルでは、実行時のパフォーマンスや安定性についての評価を行なうことは難しいですが、明らかに異なるのは生成される実行ファイルの大きさです。
VB2005の「Release」フォルダ
こちらが「Visual Basic 2005」でビルドした「Release」フォルダです。

VB2008の「Release」フォルダ
こちらが「Visual Basic 2008」でビルドした「Release」フォルダです。
上の「Visual Basic 2005」のフォルダの「exe」や「dll」のファイルサイズが明らかに小さくなっています。 両方とも、コンパイル時のオプションは初期値から何も手を加えていませんから、「Visual Basic 2008」の方がより最適化が進んでいるのだろうと想像できます。
.NET Frameworkのバージョンを「2.0」のままでビルドさせた場合でも、「Visual Basic 2008」でビルドさせた実行ファイルの方が数パーセント小さくなっています。