Seu ponto de vista é realmente interessante, mas tenho que discordar em alguns pontos.

Cada evento (hipótese-MVP) é na verdade um produto concreto. Criar uma arquitetura que suporte vários produtos é loucura pois, ao publicar um produto, não se tem certeza nem quais as features as próximas versões possam ter, já que o mesmo deve moldar-se as necessidades de seu público, nem mesmo se ele terá futuro, mesmo sendo isso o mínimo que se espera.

O desenvolvimento de software granular existe por vários motivos, dentre eles a incerteza e a necessidade do feedback de quem o utiliza, moldando-o aos poucos as necessidades — daí a sua proposta de ter uma arquitetura que suporte mudanças.

Entretanto, todo software tem um core business e este dificilmente muda sem que hajam mudanças bem drásticas, acarretando até mesmo uma completa reescrita. Esse core business deve estar presente no primeiro MVP, já que ele é a “alma do negócio”. Se sua arquitetura não permitir mudanças relacionadas a este mesmo core business o problema não está na arquitetura, mas na sua compreensão do negócio.

Tentar criar uma arquitetura que se adapte a vários produtos é, na minha opinião um enorme desperdício de tempo e energia e, pelo menos pra mim, recuperá-los é sempre difícil.

Lançar o primeiro MVP, que funcione, é o que, muitas vezes, coloca o produto na frente dos concorrentes. Não estou dizendo que o primeiro MVP deve ser feito as pressas da maneira mais rápida, e portanto mais mal feita, mas tentar prever o futuro através de uma arquitetura flexível a negócios diferentes pode matar seu produto, é importante encontrar um equilíbrio em tudo isso.