One thing I always try to keep in mind when evaluating software is the context in which it is written.  Rarely have I ever written a piece of software that I couldn't go back 6 months after the fact and find places where it could be written better or architected differently.  At the time I first wrote the software, there may have been time constraints or knowledge constraints which dictated a certain design.  It is difficult to tell in every case, but given enough project history it is not hard to piece together the context for DotNetNuke. Unfortunately, for most programs there is very little opportunity to go back and rewrite code just for the sake of rewriting it.  This is even more true in frameworks and APIs.  Once a framework is written, and people start to use and extend that framework, then it, for all intents and purposes, becomes frozen.  While it is possible to add to the framework, you will rarely have the opportunity to re-architect it because of all the other code that now depends on the API continuing to function the way it was originally developed.  In many cases, these dependencies extend beyond the syntactic contract of the API.  You will find instance after instance where applications rely on semantic behavior, so something as seemingly minor as returning an empty string instead of a null string to avoid Object Reference exceptions can have a huge impact on code which may have relied on that null string to indicate a certain application state.  So in fixing some obvious errors you introduce others, which because of the semantic nature of the dependency may be even harder to detect.

As for the use of controller classes and data classes not being OO, I would have to disagree.  If you look at Martin Fowler's seminal work on design pattern's you will clearly see that Data Transfer Objects are in fact a valid design pattern which has it's place within any given OO design.  Some would argue that because DNN is not necessarily a distributed application that the DTO pattern does not apply.  If I were building DNN as a static application for my own personal use, then I might not use the pattern, however, the minute I decide that DNN will be a framework, to be used and extended by others, then it becomes a valid design consideration to account for the case of distributed calls into the system.  There are many people who have extended DNN with webservices to enable desktop or remote application calls into the framework.  Without DTO's these extensions would have been very difficult, to the point of almost being impossible.

While one could argue from a purist design perspective that the overreliance on DTOs is bad, I would counter by saying that design consistency is equally important.  Think of this as denormalization for the sake of useability.  If every API required a complete relearning of the foundational understanding of how the system operated then you greatly complicate the learning process for that API.  Given the level of consistency throughout the DNN API, developers can look a a new API and quickly come up to speed on the semantics involved in its use.  There is a controller and there is an info object (or data transfer object).  My controller classes accept and return info objects, and I as the consumer of the API, can decide if I will use these info objects locally or remotely or both.

So, even if you may not agree with the design, at this point, it is what it is.  Changing it is not something that is likely to happen.  Given the size of the API and the size of the user community that has already extended it based on the current design, then it is extremely unlikely that such a fundamental change in the core architecture will occur, especially when there are much bigger items of concern that need to be addressed.