First, the history lesson ... ACS 4.x was originally written for Oracle, and took advantage of that RDBMS's hierarchical queries (CONNECT BY). The tree_sortkey mechanism for PG was developed by Dan Wickstrom and myself to give us a way to work with trees in Postgres when we began the migration project.
Adopting this for Oracle would've required a lot of rewriting of existing Oracle datamodels and queries, not to mention the generation of a great many upgrade scripts. Far too much work for us to consider at the time on top of the migration work, the kernel work for the support of multiple DBs, the fixing of a very very large number of bugs in ACS 4.x, etc.
It also would've violated our goal of being able to support existing ArsDigita ACS 4.x Oracle packages directly and without modification with our OpenACS core. The simplicity of the migration process from traditional aD ACS 4.x to the Oracle version of OpenACS was extremely important early in the project - we picked up a fair number of skilled people for the project this way.
Now ... when OpenForce wrote the Forums package, they did use sortkeys in the Oracle version. I helped them figure out how to do it - turns out the datatype that's wanted is RAW, not VARCHAR (VARCHAR would have the same problems it had when we first tried it in Postgres). Works fine.
Why not migrate over entirely? Well, to be honest, I want to investigate the hierarchical queries supported in (I think) PG 8.1 or whatever 7.5 got renamed to, to see if we can get rid of the sortkeys.
Because the sortkeys do take up a fair amount of space, and slow insertion of objects, without providing any particular benefit in execution speed AFAICT. You also have to add a sortkey for every class of hierarchical query you want to support, i.e. forums have the basic object tree_sortkey and the forum_message type itself has a second tree_sortkey used to do the threaded post mapping.
Oracle 9 and 10 have both removed some of the most annoying restrictions on CONNECT BY, too, making those queries easier to right.
Moving away from tree_sortkeys is a lot easier than moving to them, because you only have to rewrite queries, not the datamodel (other than to remove tree_sortkeys if we want).
Of course a lot depends here on the efficiency of the PG hierarchical queries.
Now before the PG folks announced the addition of hierarchical queries I had been thinking about moving in the sortkey direction for Oracle, too, long-term for the reasons you mention but moving the opposite direction is more attractive now (assuming, once again, that the PG folks have done a good job implementing hierarchical queries).
