I don't think that this framework really makes it much easier to use the Customizer. Ultimately, you're just passing it arrays of options which is exactly how the Customizer API itself works, and you won't end up saving many lines of code. While it removes the need to create settings and controls separately, on the other hand it raises the barrier to entry for anyone who starts looking to do more advanced things with the Customizer, as they must then learn the actual API, which is only slightly more complicated. Removing the direct ability to do things like set capabilities doesn't actually simplify the API, since you can just leave those parameters out if you don't need them. The core Customizer API is actually very well-designed and is easy to pick up as you start with it, even if you're just copying & pasting for a while.

The other issue with Customizer frameworks is that they'll ultimately move slower than, or miss out on, improvements to the Customizer in core. The textarea control type is in core in 4.0, along with support for arbitrary types, control descriptions, and much more. Frameworks would have to implement new features as well, and looking through the code here it really doesn't make it any easier to develop for the Customizer (and I also see some pretty fundamental bugs in it).

Of course, the exception to all of this is specialized controls like a typography select or advanced color palates like WordPress.com uses. But those should just be distributed as custom controls, not entire frameworks, and could eventually be added to WordPress core if they have broad enough use cases.