Very few programmers have the luxury of toiling on their code for a really long time - we are expected to churn apps out in a quick manner. Which means that to be productive, we must use tools that enable us to be that. So let's get practical, religion aside, with an eye on programmer productivity, here are the top 10 reasons why VB.NET is better than C#, in no particular order

1. The amount of data casts and conversions in C# is gigantic. There are probably 10 casts per 50 lines of code. Most of the time these casts are totally unnecessary, like in this common example. I normally save the state of the form either to Ini file, Registry or XML file. So on application startup, I restore Form's state:

   //get the form state from Ini File
   			
   //following line fails
   FormWindowState eState = oIni.GetValue("FormState");
   	
   //must use cast (FormWindowState)
   FormWindowState eState = (FormWindowState) oIni.GetValue("FormState");
   			
   //even this does not work
   FormWindowState eState = 1;
   
   //you have to use a cast even on simple numbers
   FormWindowState eState = (FormWindowState) 1;
   			
   //finally set the value
   this.WindowState = eState;

   So here we have a case where Form.WindowState should accept value such as 1, but refuses to. IMO, the compiler should be able to convert on the fly. I don't mind strong typing. I do mind stupid typing. In VB.NET all the lines below work.

   me.WindowState = 1
   me.WindowState = val(oIni.GetValue("FormState"))

   
   
   
2. The Intellisense in VB.NET is smarter than the one in C#. The most maddening example involves enums. Consider these screenshots:

   C#	VB.NET

   Note that in C#, you had to type out the enum type (FormWindowState), before Intellisense appeared. Which means you had to remember what it was. While in VB, the intellisense appeared right after the = sign, sparing you the having to remember the enum type belonging to the WindowState property.
   
   Intellisense in vb.net goes beyond this. Let's say you declare your variables in mixed/Hungarian notation, and then type my code later all in lower case. VB.NET autocorrects the case. It is a quick visual confirmation that your syntax and variable names so far are correct. Thanks to Jai Lue for this insight.
   
   
3. Optional Parameters. Even though it is syntactical sugar, it helps you code faster. 'Nuff said.
   
   
   
4. With..End With construct. Does anything else need to be said? Really?
   
   
   
5. Handles keyword. Currently in C# you have to setup the signature for the event handler and and then provide the function elsewhere. This is like C for god's sake. Where as in VB, you provide the description of what the function handles right in the function via the Handles keyword. The word is that C# will eventually provide anonymous methods (i.e. providing event code at signature). Will reevaluate this when we get there.
   
   
6. In C#, you do a LOT more typing. The common consensus is that C# is much less verbose than VB.NET, That's a total misconception. Consider the following pieces of code and then count the bytes:

   VB.NET	C#
   'instantiate a textbox Dim a As New TextBox() 'Update some class With MyClassName .ThisProperty = "sss" .ThatProperty = "sss" .ID = 4 .Name = "Frank" End With	//instantiate a textbox - Word 'TextBox' had to be written twice TextBox a = new TextBox(); //Update some class - count how many times MyClassName had to be typed??? MyClassName.ThisProperty = "sss" MyClassName.ThatProperty = "sss" MyClassName.ID = 4 MyClassName.Name = "Frank"

   
   
   
   
7. Events. Extremely easy to both declare and raise in VB.NET. In C# you have to be a delegate expert. Consider the following code:

   Class Example
   	Public Event SomethingOccured()
   	Public Sub Method1()
   		RaiseEvent SomethingOccured
   	End Sub
   	End Sub
   End Class
   Class Papa
   	Private WithEvents oExample as new Example()
   	Private Sub SomethingChanged() Handles oExample.SomethingOccured
   		...
   	End Sub
   	
   	'or use AddHandler function
   	AddHandler oExample.SomethingOccured, AddressOf x
   	Private Sub SomethingChanged()
   		...
   	End Sub	
   End Class
   		

   As you can see extremely easy and no need to much with delegates which are a lot more code-intensive. Now, mind you, VB.NET still fully supports the delegates, but for 99% of the time standard events do the trick.
   
   
8. More refined Error Handling using the Catch ... When block. See below

   Do
     Dim attempt As Integer
     Try
       ' something that might cause an error.
     Catch ex As IO.FileLoadException When attempt < 3
       If MsgBox("do again?", MsgBoxStyle.YesNo) = MsgBoxResult.No Then
         Exit Do
       End If
     Catch ex As Exception
       ' if any other error type occurs or the attempts are too many, do the following.
       MsgBox(ex.Message)
       Exit Do
     End Try
     ' increment the attempt counter.
     attempt += 1
   Loop

   Thanks to German Voronin for this.
   
   
9. Another reason is the Switch Block(Select case) syntax. For very large state machines this comes in very handy. Reuse of a single case statement for multiple items and no break statement required.

   c#
    
   case 1
   case 2
   case 3
       (...) // Do Action
       break;
   case 4
       break;
    
   vb.net
    
   case 1,2,3
       (...) ' Do Action
   case 4	
   

   Thanks to Brian Yule and Vashon Kirkman for this piece.
   
   
10. Ah, I am still working on this...