That's wrong. Orphan blocks still occur once in a while but they are less common with the better connection between the mining pools. Mining pools are often listening directly to each other and thus it is less likely for orphans to occur. It was more common in the past whereby the propagation of the network was much slower.
True, I first thought to exclude them from the main explorer chain, but still preserve them, to show as an additional feature, kinda of what blockchain.info does. But, as you said, when syncing the bitcoin client receives no orphan blocks, so I will either need a very long running daemon, or some kind of patch on the current source. So I finally decided to just exclude them.
I see that happening the following way. I'm currently syncing at 0.5 sec intervals, so after every sync I check 101 blocks behind. If confirmations parameter returned by the daemon is -1, i'm removing all blocks ahead and the current one, reverting all transactions and addresses, and resyncing.
In my above strategy, I'm assuming that forks of orphans beyond 101 blocks will not happen, atleast not practically. If that's not the correct way to do that, I accept constructive criticism.