Sim a implementação é bastante eficiente e isso pode ser medido de clara e empirica, é objetivo. Isso é um fato, assim como é um fato que qualquer implementacao deste mesmo algortimo usando JavaScript seria infinitamente mais lenta e complexa. Isso explica o motivo de ter uma query de 200 linhas jogados no meio de um sistema feito todo com um ORM de ultima geracao.
regra de negócio poderia ter sido quebrada pra melhorar a legibilidade, manutenabilidade
Isso comcerteza poderia ser, a query poderia por exemplo se utilizar de views e funcoes criadas no postgres abstrair parte da complexidade e aumentar a legibilidade e manutenabilidade, mas como tudo na computacao sao tradeoffs e com meu sql enferrujado consegui entender esta query em menos de 5 minutos, entao por isso acho que nenhum esforço foi feito nesse sentido.
é um fato que qualquer implementacao deste mesmo algortimo usando JavaScript seria infinitamente mais lenta e complexa. Isso explica o motivo de ter uma query de 200 linhas jogados no meio de um sistema feito todo com um ORM de ultima geracao
Tem que ver até onde isso é real, caso a caso. Por exemplo, no desenvolvimento com C# é muito comum as pessoas pensarem que o Dapper por ser mais leve que o Entity Framework e ser comumente utilizado com RAW SQL no código é mais performático, mas isso não é uma regra, pois ORMs modernos podem pegar a sua query feita em métodos e escrever uma query realmente performática por baixo dos panos, muitas vezes mais do que uma query escrita "na unha" por um desenvolvedor. E isso na verdade não é nem uma opinião, é algo que já foi amplamente discutido e testado.
E claro, estamos falando de UMA query. Se o Tabnews for crescer e as queries forem ser sempre implementadas assim, não vejo como isso pode ser facilmente manutenível e nem escalável. É comum ver implementações assim em grandes projetos? Eu tenho contato com um grande projeto legado atualmente, de cerca de 500 mil linhas, e ele é repleto de queries chumbadas. Honestamente é um pesadelo em todos os sentidos.