>なぜVB.netがいるか？というと、
>計算モデル部分が複雑なため、VBAだと力不足なのです。
>うまくクラスを分割して、継承やラムダ式を使いながら共通部分・商品固有の部分と分けて計算したいのです。

VB6時代からプログラムをやっていますので、VBA だけのプログラムも
数多く組んできていますが、オブジェクト指向っぽい設計はできますし、
結局どう整理するかだけの気もします。
共通部分をモジュールに出して、商品固有の部分をクラス化するとか
できるので、VBA が力不足の理由としてはまだ弱い気はします。
ラムダ式も。。。逆に適用できなかった場合に泥臭い基本的な
文法(If文For文レベル)で書けないと要求を満たせないとかなったら
使わない方が分かり易くなる場合もあるのでは？

先の回答にあるように、複数の Book に共通して使うだけなら
アドインがありますし、VB がそれほど有効だとはまだ感じません。

ただ、VB.NET の方がやはりそれなりの進化と呼べる部分は
多いでしょうし、理想といわれる形があるならそれで良いのでは？
アドインを作るのと、VB のプログラムを作るのと。。。アドイン
の方がコードは８割コピペで済む気はするけど、Book を操作する
ような部分を作成すると考えれば、やりたい方でいいと思います。

Excel から VB の DLL 参照すると DLL のバージョン管理も力を
入れないといけなくないかな？VB から Excel を見た方が楽な
気はします。

実体は Excel ファイルのまま、拡張子を独自のものに変えて、
VB.NET の EXE が起動するようにして、EXE 起動時のコマンド
ライン引数からファイルパス取得で、VB.NET の制御下で Excel
ファイルを開いた方が色々と都合が良くないかなぁ。。。