As an older school client/server developer, I've used by VB and Delphi for a few projects in the past. Having seen both tools, they have a difference of approach that I think is significant. The VB model is "90% of what you want to do is easy and the remaining 10% is impossible" whereas the Delphi model is "80% of what you want to do is easy and the remaining 20% is more difficult".
In the VB model, because it was such a closed ecosystem, when I couldn't do something, I'd have to go buy components from a third party or write a C library. There were multiple times when using VB I needed to write a special component in C or Delphi because VB just couldn't handle it. In addition, I was often forced to purchase third party components because nothing was available in the open source space.
In the Delphi model, with it's richer open source ecosystem, when I couldn't do something, I'd first look and see if there was an open source component that did what I wanted. At first this was relatively rare, but as time progressed it got to the point where 90% of the time, someone had already written what I needed. The additional 10% I had the option of either #1 writing it myself or #2 purchasing it.
In short, VB was easier to market because it "did more out of the box" and people making tool decisions would tend to think this was the best choice. After using it for a while and getting "locked in" to multiple proprietary third party components, it would often be obvious (to me) that Delphi would have been a better choice, but difficult to justify without stepping away from the problem. This is something to consider when buying things from companies and tools that are very proprietary. The hidden cost of making up for missing capabilities can often vastly outweigh the "safety" of choosing a tool that does more of what you want "out of the box".