For me it all comes down to interoperability between languages and knowing excatly what happens in the code. How does using the "native" .NET methods over the legacy ones impede the productivity? Were they really that big and complicated that you could not replace it very few .NET calls? I can't really answer that question since my experience with VB6 was short, and lets just say not pleasant :), but I think you get my idea. As for interoperability, there just has to be some standard, and Microsoft should not encourage deviating from it. Since .NET gives us a beautiful way to combine languages, multiple people working with different sets of methods and coming from different language background, may cause confusion to one another. But on the other hand, if they stuck to using the regular methods, everybody is happy, and noone has to research additional methods while trying to maintain or change the other person's code.
I personally don't think many people just use the regular .NET methods just to show how they have evolved over VB6 specifically. Programming has to evolve in general, and if it means I have to write two lines of code instead of one on rare occassions, I'll do it. The evolution over VB6 did happen though, and that cannot be denied, but it brought so many good things with it that I don't know how somebody could go back :).