The SMT approach is interesting from the formal point of view: you can very easily describe it mathematically and prove properties about it. However moving complexity to the client side does not mean that complexity is gone. On the contrary, the complexity grows, as it requires specific algorithms and data structures for storing on disk, for storing on memory, for membership proving, and for compressing prefixes to prevent a 20X space blowup.

Storing the size of the sub-tree in each node (or in the SMT case, it’s equivalent to the number of non-empty child nodes) allows to download the state knowing the completion percentage at all times, which is something that Ethereum lacks right now. The overhead is low, and the benefit from the usability perspective could be huge. Also, it enables partitioning the state in non-overlapping chunks, starting at different byte offsets, that you can request to different peers in parallel, but verify correctness independently.

You also assume that full nodes will pack the SMT nodes into small 2^k trees (and extend the hash function accordingly) to reduce space consumption and disk access. And each implementation may choose a different k. This however prevents a peer to request a specific tree node by hash, so either every client opts to store the tree in the same way, or there will be different and incompatible state synchronization schemes. So you’ll need to keep a map of every node hash to the tree it belongs. More complexity and space. It’s simpler if every one agrees of a single k. Therefore, the potential benefit of free choice of radix-packing may not materialize in practice.

All the remaining properties of the Unitrie can be emulated for the SMT using client-side code, but again, you will need interoperability, so that at the end you may have to pick just one scheme for all full node implementations.