Incremental rendering is based on the idea of incremental computation, which means that whenever a piece of data changes, the system attempts to save time by only recomputing those outputs which depend on the changed data.
In Aardvark those outputs are mostly pixels on a screen and data is input devices, geometry, shaders, and all other static or dynamic data entering the system.
In a way, any application is one giant incremental computation for Aardvark. A stream of ever-changing raw input data and user input entering the system, which is continuously converted to interactive real-time graphics, using the least amount of computation necessary.
What does this mean in practice? Imagine that your game or visualization tool manages an incredibly complex scene consisting of a gazillion different parts, which is implemented using Aardvark's incremental computation primitives. Now imagine further, that the only thing that changes at this very moment is the camera position. What Aardvark will do is to directly rewrite a 4-by-4 view matrix somewhere in GPU memory, nothing else. No costly traversal of scene graph data structures or similar overhead.
Update performance of incremental systems is basically independent of the total amount of data. It only depends on the rate of change of this data. Therefore if nothing changes, your application will use practically 0% CPU (no frame-by-frame overhead). Of course, if every single bit of data changes in each single frame, then there is nothing incremental computation can do for you. In this extreme case, incremental systems will even be slightly slower than a naive brute-force implementation, since they still keep track of the changes.
By the way, Aardvark itself is implemented on top of the same incremental computation primitives, from high-level application code down to the depths of lowest-level rendering back-end code. Therefore all projects built on top of the Aardvark platform are incremental by default. This also means, that all parts of the system naturally compose with all other parts - no impedance mismatch a.k.a. glue code. That is unless the developer makes a conscious decision to actively opt out.