I know, I'm from the real world too. It's a perfectly valid argument - there's a vast amount of C# samples and examples out there. It's also pretty much directly mapable to VB.NET given they share a runtime and type system, so it only really matters if you really don't want to make the effort to understand the code you are pasting.
It just striked me as a not so good priority to have when evaluating your choices for that particular decision.
I've had to work in both and can personally work in either interchangeably. When I switch between projects and move languages I spend a short while forgetfully mixing the syntaxes, but otherwise no biggie - and I do that when jumping in and out of SQL anyway.
Given that, when I was getting a project in a new domain started a while ago, it felt sensible to do it in C# even though I'd done more VB.Net at the time. We all use code samples that illustrate how different tasks are done, then adapt them for our purposes; it didn't take long to see that the samples were predominantly in C# and conversion was something of a hassle and not quite as simple as things made out. Most code worked straight away, but....
If it doesn't matter which you use for your own reasons, I don't see any advantage to not going with the herd of public samples.
Right, I think it just underscores how small the number of differences are between the two languages.
I've worked on many projects in both languages and I guess I can see why VB programmers transitioned to VB.NET but I don't understand why anyone without a VB background would use it (it's certainly not easier; I've been bit so many times by VB.NET's strange idiosyncrasies).
It just striked me as a not so good priority to have when evaluating your choices for that particular decision.