I've got no idea if you still care about this, but...
it's not the sort, it's the big outer nested loop that's killing you... the first result is returned 19.707ms after it starts, and the last is almost 26 seconds later... the outer sort starts ~1ms after the nested loop completes and takes less than a millisecond...
the innermost seq. scan on cr_folders is the real issue - it's cheap but is executed 5301 times in that example... it's also odd that cr_folders is being seq. scanned when they're all doing is a direct match against folder_id - is there any chance that cr_folders.folder_id is not indexed, or the db hasn't been vacuumed in a while?
a rough guess is (depending on your PG version and it's planner) you might see a worthwhile improvement by shifting the "and not exists (select 1 from ...)" condition above "and exists (select 1 from cr_folders f where f.folder_id = i.item_id)" and see if the planner is smart enough to take the hint about checking item_id and tree_sortkey before seq. scanning cr_folders to see if the item in question happens to be a folder...