I have a few pet-peeves:
Over emphasis on directory structure and organization:
Having complex directory structures are an annoyance, and religious debates over them leading to large scale reorganization of code even more so - especially in node where you have to refer modules through relative paths.
It is useful to the extent where models, views etc. reside in their own directories, but when you begin restructuring things into meticulously organized nested modules things get weirdly cumbersome.
Sooner or later you end up with code that kind-of belongs to multiple modules and people end up with an assortment of directories like utils, common, shared etc. spread around at separate levels of hierarchy.
I have realized that I almost never need to browse through the project tree hierarchically, even when I am reviewing others' code. Through intelligent navigation (Jump to definition etc.) and search (tag based/regex based) I always end up finding what I need much quickly.
So I am increasingly gravitating towards focussed independent modules with flat-ish directory tree.
Emphasis on verbose commenting & Tools for "documentation coverage":
If you follow BDD then your test suite already documents your code behavior - or atleast it should. And implementation should never be documented because your code should be the single source of truth when it comes to implementation.
Along with that if you use a disciplined amount of logger/debug statements, then there simply is no reason left to use verbose comments in codebase.
The above does not however preclude the need for high level overview documents/guides or API documentation for libraries to be used by other developers.
Convention over configuration:
There is nothing wrong with this. In fact I am very strongly in favor of CoC when starting out with greenfield projects.
The problem is when you have multiple libraries with strong emphasis on conventions which do not play well together. This is not so much of a valid concern in node community because things like imports are very explicit by default and monkey patching is frowned upon but in ecosystems like rails, where it is usual for code/templates/routes to be auto-discovered based on their location it is troublesome.
Such cases often arise when the codebase has grown over a few years and a large new dependency (a CMS, e-commerce plugin etc.) is introduced at a later stage. When the same happens, it is almost always beneficial to document that because of legacy lineage, the conventions recommended are not followed and more explicit APIs are used.
There is nothing wrong with legacy code dictating the structure/conventions of newer code.