There's so much truth in this.
Telerik has a online conversion tool[1] you can us, which can batch convert entire code-bases. But a 1-to-1 straight conversion cannot be done with 100% accuracy, and the tool will tell you everywhere it struggles to figure out the right C# equivalent for the corresponding VB.Net code.
I've used this tool in the past to "eliminate" the last remnants of VB-code in our organization. And when you do a job like that, on that scale, you definitely notice the differences.
A quick list of things you can expect to cause troubles (from memory and may not be 100% accurate):
- The difference in VB global/C# static semantics.
- The (default & overuse) of late-binding in a typical VB codebase. (While that wasn't an option for me back then, this can now be overcome by using "dynamic" everywhere, but that's hardly idiomatic C#)
- VB Modules can cause issues.
- For a full conversion, you'll typically have to rewrite all code using the functions and operands only found in the Microsoft.VisualBasic namespace. Not all these have straight up C#/BCL replacements.
Etc etc.
For being superficially so similar, a conversion job is actually much more work than you would typically imagine.
The rest of your points all sound like bad practice anyway so hopefully people are already avoiding them.
Welcome to the real world. I can tell you're new here :)
I just started typing this list off the top of my head and every time I typed something out I could think of one more thing. And these are just the ones I remember, so they're probably the ones that were annoying to work around in the compiler.
For example, VB Select Case and C# switch work nothing like each other.