It all started before C# existed
Back in ~ 1999, we had Visual Studio 5/6. If you were a Independent Software Vendor or corporate using Windows and needed an application written which could, e.g. track employee's time spent on projects, you had a few options:
- Forms in Visual Basic.
- MFC, ATL or Win32 in Visual C++.
- Forms in Access 97/2000.
- ASP website.
- Java applet.
At the time, we were just before the Dot-Com bubble burst, so anybody who was any good with (4) or (5) went off to negotiate stock options at whatever amazing dot-com they were attracted to.
(3) had issues with locking and overall scalability, but I saw a lot of Access-driven solutions which would shell-out to run support functions as needed.
So that leaves us with VB and VC++:
The Forms editor in VB was, at the time, excellent for productivity. You could drag-drop your components - not just buttons, labels and text boxes but the full 'OLE controls' toolbox of reusable components like clever Grids, Excel sheets or IE instances. The wire-up was done behind the scenes - everything was object-like and you just double-clicked things to add event handlers. This was very much harder in Visual C++. As a member of the Visual Studio developer support team at the time, I can remember how Visual Basic support calls were mostly about which component was best to use or how to optimize their application in certain ways. It was almost never 'how do I make an application with X, Y and Z user interface features'.
Building a rich UI in Visual C++ was a different challenge. Although there was Visual editor support for dialogs and SDI/MDI forms, it was fairly limited. The support for embedding OLE Controls (ActiveX) into MFC or Win32 was a black art, although a bit easier in ATL. Wiring up simple things like resize events or owner-draw was pretty painful, let alone the Connection Points required for custom events in components.
Yes, VC++ had the execution speed, debug-ability and flexible frameworks/libraries/UI options, but the IDE support couldn't cover all that ground so addressed the most common operations with things like Wizards, comprehensive MFC class hierarchies and 90-days/2-free-incidents support lines.
IIRC, the application packager that shipped with VB could package up your app, the VB runtime and latest common controls DLLs and supply you a standalone EXE installer that you could put on a CD and get to customers. None of this 'which msvcrtXX.dll and mfcxx.dll do you have installed?', which plagued the MFC developers.
So, for reasons of time-to-market and rich user interface, VB got a very big following.
When Visual J++ and Visual Interdev hit in VS6, it was clear that the Visual Basic IDE had won some battle over the Visual C++ one, which was fair IMHO. It was no surprise at all that Visual Studio .NET had a VB-like forms editor for the new COOL C# language.
The new Java/C/C++-like language coupled with the UI designer enjoyed by VB people for all this time gave a new migration path for the C++ people who were now done with MFC/ATL/Win32. For the VB 3/4/5/6 people who didn't like the lack of 100% backward compatibility in VB.net, this offered an opportunity to learn a new language in a familiar environment.
The reasons that VB was such a comprehensive product likely has something to do with the origins of Microsoft, with Basic being their flagship developer product, but I don't have any citations at this time.