I guess one purpose of tree-sortkey is to provide order and hierarchy in a single table design.
Well, when we inherited ACS 4.2 it was chock full of queries like "find me all the children of ...", implemented by CONNECT BY queries in Oracle. There's no such facility in Postgres. The tree_sortkey approach allows us to ask such parent-child questions in a single query, that can't be done in PG using a single "parent_id"-style column. It is more efficient than joining against a hierarchy table. It is also more efficient than the nested set approach ... anyway, we needed to be able to write such parent-child queries so needed SOME solution. tree_sortkeys are very fast on the SELECT side, slower to maintain.
Regarding context_id, yes, it has been used as a surrogate for not having a real parent_id, and some time back we agreed that it was "OK". I would like to change that someday, adding a real parent_id and removing the CR's then-redundant parent_id but that's a discussion for another day ...
