0I see things differently with regards to the reinventing the wheel piece. Most of the Framework code was extracted from the CMS and is the same code powering it, just namespaced. The Event and Profiler packages saw some larger refactoring, but that's really it. In the time since the 1.0.0 tag, different packages have grown a bit in terms of their features (see the Registry package for example) in ways they wouldn't have if they were still attached only to the CMS. So, there have been some benefits to our own code base.
Truthfully, since we have Framework 2.0 to work with for the LGPL change, it's a chance to (in essence) break some of the compatibility with the CMS and try to evolve the code, in terms of what's offered and in terms of cleaning up our own architecture. https://github.com/joomla-framework/language/pull/7
doesn't change anything in terms of features but goes a long way in modernizing code architecture, little things like that should help marketability in my opinion.
The Framework is stuck in a bad place right now without a real identity or a lot of real support for it. The LGPL debate was the first time a lot of people probably took notice that it even existed (which in all fairness, the first stable tag was only 2 months before that). It showed that CMS developers either don't want to use it or believe in the principle that everything under the Joomla flag has to be GPL and won't use it otherwise, so it has low marketability to Joomla's existing userbase. Joomla still fights an uphill battle beyond our small circles because of perceptions a lot of folks have from the last time they looked at our code or the project as a whole 3-5 years ago. So the name has really been a struggle. Some people suggested that the Framework takes a different name on, but to me that hurts the Framework too; a new name suggests new code (the Framework isn't new, much of it dates back to Joomla! 1.5 in some form) or that the Framework team intends to fork away from the Joomla! project and community to do their own thing (which there are some who would actually prefer that I think as they see the Framework as competition for developer time toward the CMS). So you have a code base that has very little support in the community it originated from, a project that isn't viewed as favorably as we would like externally, and the developers who support the Framework fading out of the picture. It's doomed to go nowhere in those conditions.
Last thought with regards to building the CMS on existing Frameworks; it's been an uphill battle for me personally just to convince people there's valid reasons to namespace our code, make it distributable separate from the CMS, or modernize the code architecture by refactoring different pieces. This is just with our own code base. I'm not sure I'm ready to fight a battle about introducing third party code into the CMS as the foundation of the application.