First, check out this StackOverflow thread. A similar question was asked about Sharepoint wikis, and the answers there both pro and con are really useful and outline the "impossible in Sharepoint" part of your question.
I'm in the middle of trying to implement a team wiki in Sharepoint right now for almost he exact same thing as you, after having used Sharepoint for team documents for a couple years. My observations:
Sharepoint Document Libraries
My experience is that Sharepoint for documents is decent. It can be flaky and you'll sometimes lose edits or have performance issues, although a good Sharepoint support team can help with some of that. I did find the Sharepoint document libraries better than storing things on the network. It makes the docs and libraries easy to link to. Judicious use of the metadata properties can make a Sharepoint list view very useful for seeing what the document is, what it's for, and what status it is in, so our analysts, PMs, developers, etc., all know at a glance who has the ball and when something is waiting on them. That was started for a project a couple years ago; today Sharepoint 2007's workflows can probably provide notifications.
There's also version control for the documents. But as some others have noted doing things in documents has overhead and flaws involved in composing, downloading, and sharing. Check-outs of documents help, but loose cannon developers can download docs, edit them, and than store them elsewhere thus defeating the version control. This has happened to us, although that's a discipline issue and not Sharepoint's fault.
Sharepoint Wiki
Per the Chris Hynes answer, friction is a good word to describe the issue. For quick reference of a team's internal infrastructure details the wiki seems to work better for us. The wiki makes the data almost instantaneously visible, without having to click a link first and wait for Word to load. Edits are quicker and easier too...and although I'm still experimenting with it, the Sharepoint wikis have version control and allow "check outs" of wiki articles.
As you and the other SO thread pointed out, compared to other wiki engines, Sharepoint is lightweight. What is it better at? Well, I'm using it because it's there, didn't require any special setup, better than nothing, and frankly, it works fine for internal stuff that doesn't have to be robust or customer-facing. It's easy to sell to the boss because it doesn't cost anything more than what we've already spent. The wiki also can't as easily be compromised by the loose cannon types I mentioned earlier, and we'd be able to view the audit trail or rollback if necessary.
It's easy to add and cross-link entries, although if you want to embed graphics, you have to upload them first to a Sharepoint library. You can edit the HTML in the wiki too, although I'm not sure what limitations there are with that, and controlling the CSS I believe is not available without security access and Sharepoint Designer. So anything other than text (like tables) is not very robust.
So far I like it better than storing everything as documents. The immediacy of seeing and editing the data gives the wiki a real edge. It is certainly easier than pulling down a document and checking it back in. With the average documentation-averse developer, it helps to remove the barriers around keeping information updated.
Something else to consider. Do you expect your devs to be enthusiastic and actively involved in editing the wiki? If so, you might want the discussion features of a different wiki engine. My developers are like most; the two things they hate most are testing and documentation. So I'm the guy creating articles explaining the build procedure, the database environment usage, the application instances, server map, the SOX documentation checklist, etc. The other devs will mostly reference it and post minor updates. Our versioning and concurrency support aren't being heavily stressed.
