Pro meu caso específico banco relacional é melhor mesmo, o sistema já prevê banco de arquivamento. Vai manter apenas os últimos 5 anos de registro no banco de produção e mover automaticamente os registros mais antigos para um banco de arquivamento, então não tem problema de crescimento infinito inerente.

E a estrutura de banco de dados é modular, cada empresa terá seu próprio banco de dados, que pode inclusive ficar em instâncias diferentes etc, então é quase impossível entrar no problema de escala. Não é uma aplicação com um banco de dados central que vai escalar horizontalmente, é uma aplicação que escala horizontalmente com bancos de dados diferentes. Se fosse algo como um monolito que gostaríamos de escalar no futuro, talvez nosql faria mais sentido.

Sobre storage procedures a gente tem muito aqui no meu trabalho, mas eu considero uma solução para um problema de projeto mal definido, migrar regra de negócios pro banco de dados pra mim é sintomas de projeto feito por desenvolvedor Full Stack que não se aprofundou direito, entendendo o básico de arquitetura e o básico de banco de dados, aplicações server side e client side com pouco experiência. O correto na minha visão é você tratar o dado e sempre salvar o mais próximo possível do formato de consulta. Precisaria de um artigo pra demonstrações etc kkk

Mas também gosto de nosql, mas nunca usei em projetos grandes, até onde usei não acho que seja aplicável pra maioria dos projetos centralizados de pequena escala.