Armazenar blocos binários grandes como arquivos é normalmente mais eficiente, em seguida, armazenar BLOBs grandes em um banco de dados. Depende.
Os GUIDs têm a vantagem de você poder criar um aleatoriamente e usá-lo sem depender de algum provedor de identidade. Usar uma ID baseada em sementes gerada em um DBMS exigiria que você primeiro acessasse o banco de dados antes de gravar um arquivo em disco, com um GUID a ordem não importava.
As revisões do documento podem se encaixar perfeitamente em um modelo de acréscimo. Ele pode continuar adicionando revisões ao arquivo sem causar muita reescrita. Ele também permite armazenamento inteligente e apenas o armazenamento de deltas que vão de revisão para revisão, semelhante ao que um repositório de controle de versão faria. Caso contrário, usar a compactação também pode fazer uma diferença significativa em comparação ao armazenamento das revisões em seu próprio arquivo.
Também pode fazer isso para evitar a criação de muitos arquivos no disco, o que, por sua vez, pode ter um impacto negativo no desempenho. Copiar em torno de diretórios ou fazer backups de diretórios com uma quantidade enorme de arquivos pequenos pode ser problemático e lento.
Talvez você não deva olhar os arquivos como "arquivos", são apenas dados. O GUID permite a recuperação. Colocá-lo no nome do arquivo permite que o sistema de arquivos ajude a pegá-lo.
Você poderia fazer sem um banco de dados, você pode importar algum trabalho que um DB já faz por você. Em uma abordagem híbrida, normalmente colocaria coisas no banco de dados em que eu consultaria (por exemplo, "Quais documentos estão no caminho X?"). Isso evitaria ter que criar meus próprios índices e tal em torno do repositório baseado em arquivos.