It appears that the SessionDocumentService is a major source of performance issues, especially for large documents. For every request the user makes on the document, the entire document is serialized and transferred to and from the database.
Some of the performance may be due to the size of the connection pool, but across two servers it should have been sufficient for the number of users who were testing. It really seemed to have to do with the sheer amount of data being transferred. On some maintenance documents (which is all we were testing), the serialized object graph was over a megabyte.
By stubbing out the service to remove the feature altogether, we were able to greatly improve server performance. That may not be the ultimate solution, but it meets UCDs needs at the moment.
Another option would be to use a shared file system for such a store, since that would be faster to access than via the database connections.