The researcher used as an example a recent submission with a novel research method. The other reviewers were caught up in the minutia of the paper, and missed the forrest for the trees: the method itself was more than a worthy enough contribution to the field to be accepted, and they were arguing about significance of the results. Over the course of the next couple of review rounds, this researcher's focus shifted from reviewing the paper to defending it to the other researchers. In the end, after multiple rounds (and likely a couple of years), the vote was 2-1 to reject. At this point the Senior Editor stepped in and published the paper without further revision.
Do we do the same with submissions here?
That conversation was hit me pretty hard, and I hope it will change the way I review.
Fitting in with the community style/idioms is rather important for a project, especially as it grows in size. When it's a huge codebase, used by many, in many different use-cases, people being able to look into the code to help sort out their own issues is hugely valuable. If someone who knows your programming language and knows your problem domain gets scared off by how your software is architectured/functions, that's not a particularly good sign.
But maybe the problem is huge, and all that complexity is needed, and will pay-off now they're looking to have multiple VM providers. But criticism of complexity shouldn't just be tossed aside as 'trashing'.