Costumo fazer comentários semelhantes aos de Pekka, mas acho que a razão pela qual não podemos rir disso é a sua afirmação "Esta informação, no entanto, pode variar muito". Isso significa que não é realista planejar analisar tudo e projetá-lo no banco de dados.

Não posso responder a todas as suas perguntas, mas posso responder a algumas delas.

Mais notavelmente, não posso falar sobre o desempenho no MySQL. Eu vi isso no SQL Server, testei e descobri que o SQL Server executa em extrações XML de memória muito lentamente, para mim parecia que estava lendo do disco, mas isso é um pouco exagerado. Outros podem contestar isso, mas foi o que encontrei.

"O Mysql pode substituir bancos de dados orientados a documentos como CouchDB/Sesame?" Esta questão é um pouco ampla, mas no seu caso, o uso do MySQL permite manter a conformidade com ACID para esses pedaços XML, supondo que você esteja usando o InnoDB, o que não pode ser dito automaticamente para alguns desses bancos de dados orientados a documentos.

"Como e por que eles são melhores/piores do que um aplicativo dinâmico que armazena vários dados como atributos?" Acho que isso é realmente uma questão de estilo. Você recebe pedaços XML que são (presumivelmente) documentados e o MySQL pode navegar por eles. Se você apenas mantê-los como tal, você economiza uma etapa. O que se ganharia convertendo-os em outra coisa?

Os documentos do MySQL sugerem que o arquivo XML vá para um campo clob. O desempenho pode sofrer em documentos maiores. Talvez então você identifique os subdocumentos que deseja quebrar regularmente e colocar em uma tabela filho.

Nessa mesma linha, se houver subdocumentos específicos que você sabe que deseja conhecer, você pode criar uma tabela filha, "HasDocs", fazer um pequeno pré-processamento e preenchê-la com nomes de subdocumentos com seus respectivos conta. Isso tornaria a análise estatística mais rápida e também tornaria mais rápido encontrar documentos que tenham determinados subdocumentos.

Gostaria de poder dizer mais, espero que isso ajude.