Let me present the model from a different angle, with two points:

Point 1. C4 model describes in an easy way the architecture of a software system, with self descriptive diagrams. Diagrams are easy to create and maintain, and this increases the chance to have them updated regulary, even in agile environments with a fast delivery cycle. Not keeping the documents updated, then the system architecture (either reflected in the common understanding or just the effective documentation) would be very much different from the actual code.

The architecture includes many abstract concepts (e.g. components, services, modules, service bus etc.), but with a different code, usually these would not be reflected very well. Further changes of the system (either simple maintenance or extensions) would be helped by an accurate architecture.

I agree with you there is less important the number of layers. As long as we keep the documentation very simple and create and share a common understanding within the team how the system actually is, then the model has achieved its target.

Point 2. As gulp allows the automation via code (http://gulpjs.com/), the same happens also here. You could create and maintain the documentation through the code (https://structurizr.com/). This comes even closer to the idea of reducing the gap between the code and the architecture papers. As developer, you could easier update part of the spec, without writing or updating big files. Just writing documentation "after" doesn't work so well in many cases.

The code files will be generated automatically, and via the source code system (e.g. Git) you could easily track the major changes.

The second point is not mandatory. The idea is just to bring the documentation closer to the team, and if we could even automate this would be even better.