Well, we use Sharepoint at our company, a reasonably large global SI. I see it as a necessary pain, myself. We share a lot of material across more than thirty countries, and I don't think sending that much SMB directory detail around to do the same thing via file shares is a particularly good use of time or bandwidth. Just listing directories on a server - geez, even the servers themselves - is a slow process when you're on the other side of the world, and we have a decent networking budget and some very, very good network people.

That said, it's still a slow and uncomfortable alternative. The UI is a bit below par for anyone who has used a decent content management system, but I don't think that's really the problem. The problem is it's slow. You can learn the clicks if the response is good, but delays get people all bound up in navigation.

It's based on SQL Server as a storage medium. That's a decent enough database, but it's still an RDB, and the delays in setting up connections to that database, plus all the TCP overhead bouncing from router to router in establishing that connection adds seconds to your session, seconds you wouldn't feel if the files were stored locally (to say nothing of the compression-decompression overheads).

I think there's a fundamental misconfiguration to most Sharepoint sites, and that's the major source of its clunkyness. Using a database designed for speedy delivery of TPC-sized transactions, and using it to store whole large documents may be the best way to get Microsoft-based content available on a Microsoft-shaped browser perhaps, but it seems to me there's a lot of indexing and leaf balancing to get in the way of really crisp performance unless you're very clever with the database and have a lot more RAM available to cache it than appears rational on the surface.

I'm not sure if there's a lot of scope to improve that, but some would certainly be appreciated. I think it needs a custom database designed to purpose, not the general purpose SQL Server engine. Just a feeling* I have.

Cutting the number of hops somehow would help - perhaps a store-local and replicate model would do a better job; something like the block-level geographically distinct replication of fault tolerant disk farms perhaps (Didn't Exchange public folders work on this principle once?) but I don't know how I'd go about doing that.

*A feeling perhaps helped along by 10 years as a DBA, and a year or so as a Sharepoint SME and a few years as a network engineer (basically I know just barely enough to be dangerous with it - I could be old and out of touch).