The "typical" setup before Klipper was Octoprint on a Raspberry Pi and a 8-bit board connected by USB. This setup ran into a lot of space / runtime / etc. issues for implementing advanced algorithms (or simply delta kinematics). Octoprint mostly just passes GCode to the 8-bit board which has to do all calculations.
With Klipper, the've split the workload so that both systems do what they are better at. The faster non-realtime processor does the heavy lifting regarding motion kinematics and the slower realtime controller does the synchronized moves. This allows for additional flexibility as it's much easier to have a modular linux tool and keep the uC firmware common.
I think the uP/uC split is a good alternative to bigger and more expensive boards like the Duet Series of boards.
I still like the idea of a microcontroller doing the low-level work mostly controlled by a higher level microprocessor/SBC but it seems unnecessary?
It's an interesting (and somewhat puritanical) approach to embedded systems design that mercilessly evicts functionality out of the microcontroller and into software on a higher-performance computer. The microcontroller executes a pre-planned time-scheduled queue of actions sent down from a process on the heavier-iron machine.
The model has made it very easy to port to a huge range of hardware and to do slick things like synchronize and distribute tasks across many disparate microcontroller nodes.