1) Pace of evolution: ASP.NET has evolved much more quickly and eficiently than DNN. It is now very easy to build a portal with ASP.NET 2.0, using the same approach used for DNN. With DNN, you have to deploy a new "environment" that is not really friendly, the instalation of DNN portal, skins, containers, modules, database continues to be THE pain in my back. In ASP.NET 2.0, you can develop with Visual Studio or Visual Web. For DNN, you develop with the same tools, but there is this middle block called DNN between your codes and your results in the screen. This meeans that at the top of learning ASP.NET, you also have to learn DNN. And DNN, instead of becoming simpler with time, has become a language of its own.
Personally for a software product I find that DNN has evolved fairly quickly. The addition of support for AJAX technology came shortly after the release of Microsoft's AJAX 1.0, the upgrade to .NET 2.0 also came farily quickly as well. Yes, there is an education void that must be filled to handle the installation processes, but you will get that no matter WHERE you go or what solution you use. There is no "drop and go" solution for deploying changes, and personally I doubt there ever will be!
Also DNN is a Framework and I don't think that DNN tries to shadow that fact. By definition yes DNN is another tool that you will have to learn, if you want to integrate to the DNN core you must learn the API and examine the source to find what you need. I would say that this area is the most lacking right now in DNN as the amount of public code documentation is minimal (and that is being nice). I hope that the core team will adopt a process to resolve it.
As for DNN becoming simpler, the core API is not geared towards end users, it is geared towards developers and as more complex items are implemented in the core it will get more complicated, again, I don't see a way around this.
2) SEO Friendly: Most of the time, it is not SEO Friendly, and the paths are not relatives, so you must be a skilled programmer to figure out the little tricks on how to make it work. The documentation is poor compared to the HUGE information on ASP.NET, ready and at your fingertips through a simple search with Google.
I will agree that this is another area that needs a bit of work, but personally this is something that is more guided by the module developers than it is by the core. Yes, the core has its part but it can only take it so far. As for documentation, Yes DNN doesn't have a big centralized store with every bit of documentation under the sun like Microsoft does, but personally if you search google the right way or use searchdotnetnuke.com you can find almost anything you need.
3) OPEN SOURCE? For the last 5 years, I have not seen many new faces at the "management" of DNN, I guess this is the simpler indication that DNN is evolving around a selected group of people, and this differs from the OPEN SOURCE ideology, wich is what DNN is aimed for.
I don't think having a static management body is a bad thing for an opern source project. You need to have some individuals in control of the release processes and other items to ensure that in one way or another that a stable build can be released.
4) MODULE DEVELOPMENT: To Develop a MODULE continues to be dificult as hell. You need at least to know about SQL Server, Visual Studio, IIS, and especially, about DNN itself. I would like to open Visual Web and to test my module the same way I test an ASPX script compiling in visual web. Then, upload it to my web site and that's the end of it. Instead, I have develop in Visual Web and THEN adapt the module to DNN (with little or no documention to help). Anyone that develops modules of average complexity knows what I'm saying: modules are developed in visual web and THEN ADAPTED to DNN. This a double (and improductive) work. Better develop everything from the scratch, instead. Permissions, role management and security permissions are ALL adressed in ASP.NET 2.0, and this, by itself, makes DNN obsolete, i'm afraid.
I find some of your statements in here very inaccurate, there is not any "double building" needed to build DNN modules, I build modules all the time for DNN and I always just build them right to how they need to be for DNN and I never build them "this way" then "adapt" them to work in DNN.
Yes, again I will admit that the documentation on DotNetNuke.com is lacking but members of the community have really stepped up on this one and some very good documentation exists (http://dotnetnuke.adefwebserver.com for example). Again there is a learning curve to do things within the DNN Framework way of development but this is something that should be expected with a development framework.
Yes, ASP.NET provides features for roles, permissions etc, however there is still a lot of interface work and functionality that DNN provides that is not "just there" in .NET 2.0. However, the one thing to note is that with ASP.NET there are more times where DNN might not be the best solution for a specific problem, it might be easier to just roll your own using ASP.NET
I don't want to start a flame war or anything here, but I just wanted to voice my take on the matter as a very activly contributing member of the DNN community.