While I agree with pretty much everything prole writes, my overall assessment is very different: I love VB.NET. This is mostly because most of what in the writeup looks like a criticism of VB.NET is neither a bad thing nor specific to VB.NET. Some examples.
MyBase designed to make you feel like a five-year old?
As prole clearly states, the concepts of MyBase and Me are not specific to VB.NET; they are common to most object-oriented languages, including Java, and their common predecessor, Smalltalk (1975), which knew them as self and super. Now Smalltalk was in fact designed to be a programming system that five-year olds can use, so MyBase is indeed a concept in VB.NET designed for use by a five-year old. The unstated assumption, however, is that this would be a reason to shun VB.NET and prefer Java instead. Java has the exact same concept. It just uses a different name for it.
How Microsoft convinced so many people that You can do x without writing a single line of code!?
This was what Smalltalk set out to do, its single great innovation. To programming language specialists like you and me, object oriented programming means language features such as inheritance, polymorphism, methods and messages, up to and including the MyBase concept. To Alan Kay, one of the Smalltalk inventors, it means putting programs together by direct manipulation of user interface objects. Yes, Microsoft's programming tools, which take great effort to support this approach, have managed to convince very many people that the approach actually works; what is more, the many applications produced with them constitute proof. This is hardly surprising, since it rests on a great deal of solid research, performed by the Smalltalk team and those who came after them, including Microsoft. There is nothing factually wrong with the remark that Microsoft convinced many people to put software together this way; what is wrong is the implicit assumption that other object-oriented languages or tools are somehow to be preferred for that reason. It is like saying: I love E2, except that it's so easy to contribute to. Furthermore, there is nothing VB.NET specific about this criticism: Microsoft's tools support other languages such as C#, managed C++, J#, C++, VB6, JBuilder does it for Java, the Smalltalk system did it in the seventies, and any modern IDE for any language must do it if it wants to be successful.
As prole already guessed, most of them were taken from VB6. This is hardly surprising, since VB.NET is nothing but C# for VB6 programmers: its syntax is as close to VB6 as possible, and it comes with a whole array of predefined functions that correspond to VB6 equivalents; supporting the VB6 keywords was a design goal. The need to stay close to VB6 also produces silliness such as the "q"c character denotation syntax. Again, proles comments are right on the mark, but what is the complaint here? These features were designed for VB6 programmers; if you don't know or like VB6, VB.NET wasn't meant to be used by you - use C# or some other .NET language.
Wrapper classes
If prole needs to make a primitive type a little more flexible, she can write a wrapper class for it. If Harry wants to make the same primitive type a little more flexible, he can do that, too. He will. And I will. And any other programmer will. Wouldn't it be nice if the language automated this process so we could actually save some work and share the same wrapper classes, be convinced that they are correct out of the box, and so forth? That is what VB.NET does. Except that it is actually .NET which does it, so all languages that compile to .NET support this, including VB.NET and C#.
The same is true for structures, a compromise between value types and objects. I don't like them any more than prole does, but they are a .NET feature. Good barking, but VB.NET is the wrong tree.
Statement separation
VB.NET does have a statement separator: :. In fact, it has two: newline is the normal one. I wouldn't use anything else: putting multiple statements on the same line is poor coding style. Teach a writer how to use layout, and he might be read one day. If C or C# had had the nerve to apply such an advanced concept to their if statement, they would have saved us from a whole category of bugs. Of course, there is such a thing as job security.
Whitespace-dependent &
OK, so the compiler isn't sure how to read a& b, since a& is a valid expression, and has nothing to do with string concatenation. The ternary operator looks like a function: IIf. VB6 compatibility strikes again.
No ++
Wait a second - being able to mistype a++ + b as a + ++b is supposed to be a good thing? Sure, C's ++ operators made sense, because they were in the PDP 11 instruction set. I don't think VB.NET is used much on the PDP 11.
Sub versus Function
I don't know about you, but when I declare a function in C, C++, or Java I have to say whether it returns void or not. What does void mean, anyway? It means that the function is really ... you guessed it, a subroutine! Sure, understanding void makes me feel like a grown-up; I was taught programming in Algol 68, the language C took it from, and Algol 68 has a need for void, since it has a type system in which functions are regular type constructors. In C on the other hand, void is little more than an excuse to cast function arguments to void * that the programmer can't be bothered to type correctly. I prefer VB.NET, which supports properly typed function arguments in the form of delegates.
In programming languages, the evaluation of arguments of logical expressions can have side effects, and takes time, so evaluation order matters; in standard predicate logic, it doesn't, so logic isn't any help in deciding in which order evaluation should happen. Always evaluating left to right, like Java does, seems to be the best approach, but many programming languages, like VB6, require both arguments to be evaluated. VB.NET, thorough as it is, offers both: And and Or preserve VB6 semantics, while AndAlso and OrElse are for the rest of the world. Run FxCop to get the list of Ands and Ors to replace.
Indeed, VB6 programmers like their type conversion functions such as CInt, CDbl, so it is no surprise to see CType for performing a similar conversion. To just cast, use DirectCast.

In summary: every single point raised is a valid issue, but none of them represent specific VB.NET concepts or shortcomings; yes, some of these concepts turn out to work for the five-year olds they were designed for, and yes, that eats into your job security. Let's all go back to fixing buffer overflows in string operations.