Your usage of "wiki" here suggests you meant Confluence (an Atlassian product) vs just "why use anything Atlassian offers", but I think the answer is the same.
Disclaimer: I'm not necessarily advocating for choosing Atlassian's suite of products over a handful of separate open source tools, but just offering a guess from what I've seen at companies I've worked for.
I believe people choose Atlassian's tools as an overall package, often surrounding their issue tracking tool (Jira). If you happen to use/need/prefer Jira for your issue tracking, the wiki-like tool that Confluence offers just happens to be integrated tightly with Jira (and their other tools). If you've already chosen Jira (say) and you need a wiki (Confluence), or a git repository (BitBucket), or a status page system (Statuspage), etc, my guess is Atlassian bundles and integrates this all together in such a way that companies just go for the total package.
To your point, I'm not sure why someone would use Confluence as a wiki over some other wiki software, assuming they had no interest in integrating their wiki with a bugtracker, git repository, etc. I think the selling point has always been the bundling/integration.
I think that’s a fair point to make. What would you say about something like Trac, which is also open-source, includes a wiki and rolls in git along with subversion. Really I guess the ask is this:
Why even bother trusting someone else with reliably hosting data?
Perhaps I'm not up to date on Atlassian's hosting options, but every company I've ever worked at which uses Atlassian (including my current) hosts the servers themselves, I believe. You pay for the software/licenses/updates, and Atlassian simply hands over a pile of Java jars and documentation. It is up to your ops staff to choose a server, fire it up on there, back it up, update it, etc. This would be the same as running your own Trac, right?
The current issues people are running into are the ones who went for the cloud hosting option.
Some do run it onsite which is similar to running Trac but with two major differences:
1. Contributing bugs to Atlassian helps only Atlassian.
2. You have to pay Atlassian.
The counter argument is that a company of Atlassian or even further scaled, at Google’s size, should be able to provide some meaningful customer support or engineering around bugs or issues while using the platform.
But in reality, Atlassian’s cloud outage is over 2 weeks, could have likely been resolved if everything was handled properly on-site (for those who like to play Devil’s advocate, there’s your hinge) as opposed to going to the cloud.
What I’m arguing for is the idea it’s beneficial to everyone to support platforms which enable the user to DIY, and we consider engineers or admins people who do that: Engineer and admin.
In other words: the car industry doesn’t compete over the shape of the wheel, why do we?
If self-hosting is the best option for you, do it. I won’t judge you. I just don’t want to take that option for myself, and I don’t want to be judged for it either.
Disclaimer: I'm not necessarily advocating for choosing Atlassian's suite of products over a handful of separate open source tools, but just offering a guess from what I've seen at companies I've worked for.
I believe people choose Atlassian's tools as an overall package, often surrounding their issue tracking tool (Jira). If you happen to use/need/prefer Jira for your issue tracking, the wiki-like tool that Confluence offers just happens to be integrated tightly with Jira (and their other tools). If you've already chosen Jira (say) and you need a wiki (Confluence), or a git repository (BitBucket), or a status page system (Statuspage), etc, my guess is Atlassian bundles and integrates this all together in such a way that companies just go for the total package.
To your point, I'm not sure why someone would use Confluence as a wiki over some other wiki software, assuming they had no interest in integrating their wiki with a bugtracker, git repository, etc. I think the selling point has always been the bundling/integration.