Kiwi is indeed a replacement for Casuarius/Cassowary, and as you mention, it was a non-trivial undertaking. So, why did I do it?
The simplest answer is that I wasn't happy with the performance of the existing solver and the end-of-year/holiday time is the perfect time to do this kind of work (replace something that works with something that works better).
A perfect use case of the previous solver being slow is with a Form. The Form, while seemingly simple looking, actually generates quite a large amount of constraints under the covers. If you have a form where you are dynamically inserting rows, the performance will visibly appear sluggish ~15 rows. For my standards, this is simply unacceptable. If you were to instrument the old layout engine, you would find that solving the constraint system on a resize was ~10x more expensive than setting the geometry of the underlying widgets with the solved values. So with respect to the layout engine, the solver was the bottleneck.
The new solver removes that bottleneck. It still uses the same Cassowary algorithm, but it's a from-scratch implementation of the algorithm based on the Cassowary paper, not the existing Cassowary source code. While the Cassowary algorithm is good, the existing C++ implementation has lots of inefficiencies. The new solver is anywhere between 12x and 500x faster depending on the problem (40x typical) and uses around 5x less memory. And as I typically do, I chose to write the Python bindings by hand in C++ rather than use Cython. The resulting code is faster, and we now have one less external dependency.
I hope that answers your question!
Cheers,
Chris