Take a look at the Capacity Planning guide - it's recommended that you not
exceed 2000 documents or list items per folder  for exactly the reason you are
seeing.

I've read the capacity planning guide, but it doesn't really help.

I'm storing about 50,000 documents, and they have already been split
up into different folders. I really don't want to have split them up
any further.

It really does seem very silly that you can't store more than only
2,000 documents in a folder  without experiencing slow-downs.

What is the reason for these slow-downs? All of the documents are
surely stored in the same database table regardless of which 'folder'
they are in?

Are there any known workarounds?

The limitation is in the underlying code that enumerates items in a folder  (so
you'll see it everywhere - OM, Web UI, Web Folders, etc), and the only
workaround is to not store more than 2k items per folder.

I experimented this issue at length with a client. Basically we were
posting InfoPath document  to a form library  programmatically, after 1500
documents, the code the post was slowing down dramatically. We narrow
down the problem to the method

Add from the SPFileCollection class was the root of the problem

Microsoft gave us 2 suggestions:

1. split your form libraries in folders, we programmatically
created folder  for each day as forms were being added
2. Use a different method to post document, i.e. use the URL
protocol with FrontPage RPC or whatever (not really fun)

The limitation in the Add method is a bug that Microsoft should have
fixed. Basically we track down the stored procedure and for some unknown
reason, the code is issuing a full record locking on the records that
are part of the Docs table before inserting any document, which is
causing tremendous pressure on the SQL back end.

There are no workaround, just make sure that your document library
contains folders  if you want to exceed the 2000 document limit. BTW the
real limit is 2,000,000 documents per library