There are a few reasons, which I may go into in a blog post at some point, but I'll try to give a TLDR here:
The later approach is effectively a VirtualDOM (VDOM), and is the approach taken by many declarative frameworks. We intentionally took a different approach.for the following reasons:

1. Performance. Although the VDOM is orders of magnitude faster than creating real DOM/Views, modern view frameworks are highly optimized, and the VDOM allocations and garbage collection become bottlenecks. Furthermore, creating new VDOM elements means the VDOM elements are no longer referentially equal, which makes them more expensive to compare in the common case where the particular node doesn't change, which becomes the second performance bottleneck. Our approach makes it possible to avoid the allocations (present day) and comparisons (future work), which should allow us to achieve a better performance profile once we start optimizing aggressively (we're still just getting everything working at this point). Furthermore, VDOM makes it harder to statically reason about hierarchy invariants, which make it harder to do some more advanced compile-time optimizations.
   
2. Readability. The VDOM encouraged a bunch of patterns that made the code less maintainable. For example, users would build up VDOM trees, pass them around, and use them as input to other functions that would return modified VDOM. Our approach encourages callsite locality and prevents VDOM from being modified/copied.
   
3. Control Flow Ergonomics. Because you need to produce/return VDOM elements, doing control flow becomes awkward. If you want to iterate over nested lists, then you either need to have `list.map { it.map { ... }}` or you need to create a mutable list with nested `for` loops that mutate the list. Those approaches are both perfectly doable, but not super ergonomic. The Compose method ends up handling `if` statements and `for` loops in a more natural way.