The VB Model versus the Delphi Model
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".
Comments
The key difference now is that choosing a "proprietary" vendor-provided solution like .NET no longer means locking yourself away from open source extensions to the ecosystem. NHibernate and Spring.NET have been around for years, and Microsoft has recently open-sourced its entire web application framework (including new features like MVC).
On the flip side, if you start a Rails app and decide to use a particular gem or set of gems (Devise, CanCan, ActiveAdmin, CMS's like Refinery, etc.), you begin to trade out-of-the-gate features and productivity for down-the-road flexibility, as you are necessarily "locking yourself into" these gems by coding to their APIs.
As is so often the case, it's not black and white - it's as many shades of gray as you can produce with a 64-bit graphics card. Which is not all bad - it's part of the reason there's a market for smart guys like us. :)