"But to get to the point of using the framework to solve problems that generally arise we encounter a learning curve of the framework. Although Openacs provides a certain degree of abstraction IMHO its not enough."
OpenACS is a far too much a grab bag of things. In some areas our abstractions aren't orthoganal therefore less useful than they should be (a bunch of things that only apply to the content repository, rather than all objects, for historical reasons, being the primary example).
This has more to do with a messy implementation and design history than the choice of implementation language. If a modern OO language had been used, we'd still have a system with a content repository built by aD folks on the west coast who made no effort to work with their peers at aD on the east cost, glued to the side of the ACS kernel developed by those east coast aD'ers.
That was due to poor software project (or software company) management ... not programming paradigm. Or, more fairly perhaps, it was simply a reflection of the fact that aD had a bunch of high-visibility clients demanding that complex projects get done in a short period of time.
We can't shed our history, though. That's why I fundamentally find these discussions not very interesting.
We'd make different choices if we were to start over ... but unless we're willing to start over, we're stuck with the history.
One example has to do with RDBMS support. If we were starting the project today, we'd ignore Oracle, I'm sure of it. Many of us would jettison Oracle today if it weren't for legacy users. It would greatly decrease our maintenance efforts and would simplify new development if we only had to develop for Postgres.
Yet, when we made the decision to support PG and Oracle equally when we took over the code base from aD, it was undoubtably the right decision. Malte had an early success story, being able to support a client's ACS 4.x packages on an early OpenACS core seamlessly, others had similar experiences. It gave our project legitimacy and led to a steady trickle of ex-aD'ers becoming part of our project.
But viewed from today's perspective ... man, it sucks having to support two RDBMS's. Imagine a toolkit without a single .XQL file!
History is like that.