The decision to store real data in a blob fields instead of in a table (one or more) looks quite unusual, and the solution you propose is savvy and natural.

Regarding the way to archive images and documents directly into the db. I know the cost in term of performance, due to the size of the blob fields, but, with a proper division of the DB in more than a single filegroup and the consequently mapping of blob fields to a dedicated filegroup, is possible to mitigate the performances tax.

Moreover, it's to remember the the choice to incorporate docs, files, images directly into the db (unacceptable by a noble and pure DBA) is the one adopted from MS itself for the entire Sharepoint architecture!

And the performance of a Sharepoint server aren't so bad, to discourage the use of blobs in the db. But it's strange that the structure of the Sharepoint dbs is flattened in a single filegroup: perhaps why the principal focus in these db are pages and documents and not the related metadata.