I still find coding on OpenACS relatively groovy. It's easy to create a package, write a datamodel and do relatively sophisticated things quickly.
One feature that makes that a lot more efficient and still flexible is ad_form, once you got used to it.
Of course I don't use xql files or i18n-ize my code from the beginning, and to be honest I'm also reluctant to create acs_objects unless I'm 100% sure I'll need them.
And I don't like to create tcl api's for stuff that accesses the database. If some data from the db is only needed on one page, and slightly different on another page, what's the point in generalising this into an exra abstraction? One groovy factor of OpenACS coding is to write an sql query or dml directly into a tcl file, reload page and voila - changes are in effect. Instead of changing tcl file here, change call of tcl proc there, select file to be watched etc. etc.
I'm not saying there is no point in tcl apis (and I'm well aware DaveB will come over now and beat me for this), but they should only be used for operations that really are used in many places. Otherwise they decrease the groovyness of OpenACS which comes a lot from the fact that it directly deals with the database.
Lack of philosophy: I think that OpenACS has still a good foundation in some very sound principles, which I found to be well described in Phil's book, such as the closeness to the database, two-tier architecture etc. And a bunch of best-practices that have developed over time and in sum make out the quality of OpenACS sites such as abstract urls, inline display of form errors, redirect to display page after an update with POST, etc. etc. These are not as famous as big paradigms like MVC, but they have proven to work very well in the world of web apps.
