Interestingly, your point about consultants and developers having had the time to learn from their mistake was a point made against MS not that long ago. MS switched their technologies and APIs so fast that developers had at best a few years of experience, since that's how long each iteration lasted. In contrast, a lot of stuff I picked up about X11 in the 90s is still valid.
Open source can be a bit of a jumble. We have had some experience with solutions based on a number of FOSS products working together (in many cases, one has to rely on additional modules or bits of software written by different communities). Which is fine until one of those products is no longer being developed further. Your NTLM-based SSO module doesn't work with the Kerberos based system the company is switching to, and the devs have long gone. But that doesn't really have to be a problem. If you know you'll have to replace a FOSS component, you start looking for a replacement. Worst case scenario: you pay someone to develop a new version for you, which rarely is a major effort. It's a problem when it is a surprise and it breaks things. Because then the responsible manager does not have a vendor to shout at.
That ties in to the cost element as well. Estimating price and timelines for MS-based projects is reasonably well understood and not more inaccurate than in other projects, in my experience. But to what degree do you favour predictability over a (much) lower cost? As an example: Sharepoint.
My client (a large multinational) rolled out Sharepoint and is gradually replacing other systems with it: document management, team collaboration spaces, web content management, discussion forums, and the company Wiki. Some of the software SP is replacing was over 15 years old, but it had some good qualities: it was designed to scale up as well as down, to run in a multi-tiered organisation with delegated administrative responsibilities, and though (or because) it was not all-singing-all-dancing web 3.0 ultra-integrated software, it performed well with a minimum of maintenance and ran on pretty light hardware. TCO was low, and most change requests could be executed on the cheap as well.
Now there is Sharepoint. The cost of implementation (including migration from the older platforms) would feed a small nation for a year. It requires much beefier hardware and an army of consultants: lift a floor tile in any of the datacenters and you'll see a few Sharepoint guys scuttle off. Maintenance is at least an order of magnitude more expensive. And functionally, it only offers the very barest of any of the solutions it replaced. What it does do well is integration between functions and with Office, and workflow... but compared to all the other stuff, I consider those to be nice-to-haves.
There's the problem: Sharepoint was too easy a choice for management. A one stop shop, well understood cost structure, a traditional big iron approach to run the project, and someone to blame when things go south. And the sexy integration with Office of course. However, if they would have looked into FOSS solutions for CMS, Forums, Wikis and team sites, and selected a tried and true document management system from a vendor who knows what document management is, they would have saved time, saved a ton of money, had less disappointment and frustration from the rank-and-file, and enjoyed a much lower TCO. What they would miss is integration between all of these functions, but you know what? They are not that important.