Part of the challenge we face today is that different people have different views of the Elephant that is DNN. For some people it is a framework or a platform. For other people it is a CMS. For yet a third group it is a social solution. Your view of DNN necessarily colors your approach to solving problems like "how do we incorporate a rich text editor".
One of the discussions we have been having in the Architecture working group is how to separate the various layers of DNN so it becomes easier to answer these types of questions and to provide even greater flexibility to our users. The first step in this direction will come in the 7.4 and 7.5 timeframe at which point we will look to separate the core platform from the various modules which make up the administrative and content management experience. Some functionality, like user management and permissions are a necessary part of the core platform. Other functionality like Vendor/Banner management or HTML Editing are part of a specific solution or configuration.
The goal in 7.5 will be to allow DNN Corp and the Community to package DNN into different distributions which target different groups of users. There might be one distribution which is general purpose (basically DNN as it currently exists), while another distribution would focus on users who need a good blogging or social platform. Each distribution would essentially be the "DNN Platform" (as it is newly defined) and some bundle of modules, providers, skins etc.
So, back to the question of how to incorporate a rich text editor into DNN. If I were only interested in using the rich text editor in one or two places (like just using it for the HTML Module), I would see the value of directly incorporating it into the application so that I could take full advantage of all of it's unique features.
The downside to this approach is that the task to use the editor in different places becomes much greater. Also, every module developer that also needs an editor would also need to hardcode the editor into their module. This would require a lot of effort at the platform level and at the module vendor level to get the editor incorporated across the entire ecosystem so that users end up with a consistent experience.
The real difficulty arises when we decide in two or three years that the CKEditor is no longer the right editor for the platform. Maybe the developer ceases development of the product, or it becomes a commercial product (see FreeTextBox which was our first editor). When we need to make a change, how easy will it be to get everyone who is using the current editor to switch to the new editor? Over the course of the last 12 years DNN has had three different editors, and we are about to have a fourth.
The value of the provider based approach that we have today is that we can swap out the editor across the entire application by installing a single extension. This means that the effort to move from RadEditor to CKEditor becomes possible to achieve in a single release, and doesn't require any change on the part of module developers.