厳密なプログラムが書けることのメリットはなんといっても、プログラム時に型変換エラーや不適切な型変換に気がつけることです。

たとえば、次のVBのコードは実行できますが、TextBox1に文字を入れて実行するとエラーになります。
   

Dim i As Integer

i = TextBox1.Text

一方、上記と等価な以下のC#のコードは実行できないので(実行時のエラーが発生することもありません。

int i;

i = textBox1.Text;

※この例ではVBでOption Strict Onを設定すればC#と同じ動作になります。

これをメリットと考える場合は、実行時にエラーが発生する可能性があるプログラムを、プログラム中に気がつけるからエラーの可能性が減って良いと評価するわけです。
デメリットと考える場合は、仕様によってはTextBox1に文字が入らないように別の場所で制限する場合もあるのだから、実行くらいはできるようにしたほうが良いと考えるわけです。

厳密でない場合の最大のメリットは、プログラム時にはわからないメンバーを呼び出せることだと私は思っています。
たとえば、VBでは次のコードですべてのウィンドウを最小化できます。
   

Dim Shell = CreateObject("Shell.Application")

Shell.MinimizeAll()

これと等価なC#のコードは以下です。

object shell = Activator.CreateInstance(Type.GetTypeFromProgID("Shell.Application"));



shell.GetType().InvokeMember("MinimizeAll", 

    System.Reflection.BindingFlags.InvokeMethod, 

    null, shell, 

    new object[] { });

Shellオブジェクトを生成するとところ(最初の1行目)は厳密さとはあまり関係がないので除くとして、次のようは単にMinimizeAllメソッドを呼び出したいだけなのにC#ではなにやらかにやらかかなければいけません。VBでは単純にメソッドを呼び出すだけです。

他にも型の厳密さに対していくつかの着眼点があったり、型以外にもメソッドの呼び出しで必ず()をつける必要があるC#とそうでない(=つけてもいいし、つけなくてもいい)VB、メソッドの引数も配列の添え字も()という表現で区別なく表現できるVBと厳密に区別するC#などの着眼点もあります。

それで、それぞれがいいことなのか悪いことなのかの評価は状況によって変わるので、ここだけを取り出してもどっちの方が魅力があるとかないとかは決められないのです。