As you already pointed out there are many good reason why you would store documents in the DB such as security, simplicity, transactions, etc. A lot of systems are using this approach like SharePoint for example. There are no any Telerik Data Access specifics that you should consider when making your architectural decision.
However I would not suggest you to place those files in a database if you expect to have lots of documents as this could drastically increase the size of the DB file. Bigger size of the DB leads to a performance decrease as you already mentioned. Another think you should consider is how those files should be opened for view/edit. If they are stored on the file system would be a bit easier because all you need to store in the DB is the location of the file and then the default program can open the file. If it is in the DB you should extract it in a temp file, open it and then probably delete it.
Lots of system use this approach even some document management systems. It is OK but you should really estimate how many and how big documents you will have.
If you plan to store a few small documents probably the DB is a good chose.
To cope with the performance degradation you can think for horizontal split of the DBs and have dedicated DBs for documents, even multiple of them.
I would suggest you to abstract the logic behind the document management in a Service or Manager class so that whatever you select as an approach you can easily change it later if you see it doesn't work well.
I hope this helps.
OpenAccess ORM is now Telerik Data Access
. For more information on the new names, please, check out the Telerik Product Map