Personally I do not plan to develop any widget framework on top of dcl. It can be used for that, and it was used for that (closed code), and even the existing Dojo's Dijit was tried with it (dcl can emulate most of dojo.declare). But right now dcl is positioned as a micro-library for node.js and AMD-based projects. It can be used as a part of a framework (OOP usually is not the main part of a framework anyway) to keep the base small structuring it as a set of orthogonal components.
The main motivation to do dcl was based on a bunch of "anti-patterns" I saw in real life code --- somebody wrote a code with good intentions, yet without a way to update/upgrade the code. And after a bunch of "improvements" and patches the final result was a horrible unmaintainable patchwork --- it seems like nobody was at fault, everybody had good reasons for thair hacks, yet the result was invariably horrendous. Another motivational factor was out-of-band knowledge required to use somebody else's code --- "just call it after all work is done", "call my code first, than yours", and so on, when I realized that it can be done much more safely with AOP advices.
Basically I wanted to show those two points with the introductory article, and a widget system is usually a good example of OOP, which is understood by all, even server-side programmers.