I think you are confusing Classic VB6 issues with ASP.NET.

In VB6 NGs many moons ago this question would arise on a regular basis
because the OP is confused about what the difference is between late and
early binding.

In .NET these terms are not used although there are some issues that are
similar.  In your above code the two approachs are identical and neither
relates to any form of binding.

Binding occurs when a method or property is accessed. Take this:-

Dim o As MyClass
Set o = New MyClass
o.Method()

In VB6 the call to method is early bound (also known as vtable bound) since
at compile time the compiler can determine where the pointer to the method
function will be.  OTH,

Dim o As Object
Set o = New MyClass
o.Method()

In VB6 the call to method is late bound since at compile time the compiler
can't determine where the method function pointer will be all it knows is it
has an object that has a method function.  At runtime the code has to query
the IDispatch interface for a DispID for the "method" member then dispatch a
call to it via the IDispatch interface.  Much slower.

This business with the inline new in the Dim line was very often quoted as
being related to binding but was in fact an entirely different issue
altogether.

Dim o As MyClass
o = New MyClass
o.Method()

In VB.NET the compiler can resolve exactly where the method is. In fact the
JIT native code compiler can go further and possibly remove the method call
altogether by inlining the code in the method.

Dim o As Object
o = New MyClass
o.Method()

On the face of it the compiler can't know where the Method function is at
compile time and has to leave resolution of it to runtime.  However at
runtime things are slicker since the full type information is available to
it and it can resolve where method is far quicker.  Hence this isn't really
like the old VB6 late binding where its possible to call a method of an
object whose type the runtime knows nothing about.

A new variation of this is introduced to the language when a method is
marked as overridable (virtual is C# parlance).  In this case the compiler
can't know where the method function is even for a variable typed as MyClass
since it may hold a reference to a sub-class that has overriden the method.

Note in these simplistic cases the compiler and/or JIT compiler can probably
resolve stuff more inteligently but the principle holds.