Effectively, this is assumevalid SwiftSync minus the hints file and (consequently) the hash aggregate. Rather than keeping track of a single 32 byte value, you’re tracking everything and removing duplicates via sorting. This means your memory footprint will scale with the number of (U)TXOs, similar to a regular full node, particularly since you need to keep track of more than just the outpoints in order to arrive at the actual UTXO set.
While not needing a hints file (~80MB compressed) is an upside, the significant memory footprint (and subsequent need for sorting or lookups) is a big downside. The inability to disable assumevalid and do full signature validation is also unfortunate.
What I do think is interesting is the observation that sorting can replace database lookups. I find it hard to evaluate the exact tradeoffs there, but it seems plausible that this may be beneficial for order independent addition/removal.