It may seem odd to defend the use of MediaWiki at all: after all, it's the application that powers Wikipedia, which alone makes it by far the most-used wiki software, used by hundreds of millions of people every day, whether they know it or not. Its continued successful use on Wikipedia means that MediaWiki's scalability and security are unquestionable.
And MediaWiki is the dominant software on public wikis in general, even outside of Wikipedia (and other related sites, like Wiktionary). On the English-language Wikipedia, the general "Wikis" category lists about 10 non-MediaWiki-based wikis (like DavisWiki) that are notable enough to have their own article; meanwhile, the subcategory "MediaWiki websites" lists over 100.
For private wikis, within organizations and companies, it's harder to tell - MediaWiki is probably not quite as dominant, but it still has a very significant presence.
Nevertheless, we've observed a tendency among companies to start off using MediaWiki (or a combination of MediaWiki and other open-source wiki software, within different departments), and then to a switch to an expensive, "enterprise" solution like Atlassian Confluence or Microsoft SharePoint, when they decide they want to get "serious" about using wikis. The implication is that MediaWiki is a nice application to start out with for free, but when you want to do real work with a wiki then it's time to start shelling out the big money for a professional solution.
At WikiWorks, we disagree with this assessment. We consider MediaWiki an enterprise application, and we think that it can stand up, both on a feature-by-feature basis and for ease of use, with any other wiki software, at any price. Our secret weapon in this match-up is a large and powerful set of open-source extensions to MediaWiki that we routinely bundle in for our clients, which fill in many of the perceived gaps within MediaWiki, and add in new functionality that other wiki solutions simply can't compete with. Chief among the latter group is Cargo, an extension that allows for storing data within the wiki and querying it elsewhere. This simple addition in turn allows for a lot of other functionality that enterprise wikis tend to have: calendars, to-do lists, maps and timelines among them. It also allows for creating forms to allow users to easily create and edit that same data.
In all our experience with MediaWiki, and with talking to clients about their needs, we know of only one set of functionality that MediaWiki seriously lacks compared with other wiki applications, and that's the ability to control read-access to different sets of content within the wiki for different user groups, i.e. to have pages that are readable only by certain users (controlling write-access, on the other hand, is no problem). There are different extensions that allow for this, but the solution we generally propose for this problem is to instead have separate wikis for the separate security levels - in our experience, two or three wikis at most will usually cover the need. Additional wikis are easy to set up with MediaWiki, and with user-management options like LDAP (available via several extensions), you can make for seamless logins across the different wikis.