What PL/SQL does is to extend the methods that operate on the data, maybe simplifying the interface to the database. In the case of creating an acs_object, the __new procedure handles quite a bit of effort. If this effort were moved to the tcl layer, the porting effort would extend to every page that called the __new procedure.
Far too many of the "__new" functions for types merely call "new" for their base type then insert into their table. An alternative style is implemented in the CR using the input views, which work both in PG and Oracle. These allow one to simply do an INSERT on your content type's input view to create a new revision. In fact that's how the automatic new revision generator found in cms/tcl/formprocs.tcl works. It's in the Tcl layer and rather than increase the porting effort, the same INSERT works in both PG and Oracle (and in this case happens to be automatically generated from the content type, even better).
Many, many PL/SQL functions in the toolkit are simple wrappers around simple DML. They really don't provide an abstraction layer for the most part. Some do of course and those that do aren't the ones I'm talking about.
Regardless ... I want to move to a higher-level description of OpenACS object types anyway. I get tired of writing code for both Oracle and PG that could be automatically generated for me.
