Traceroute provides a route that takes longer than 100 hops

As a comparison, when I play first person shooters online typical latency (ping times) where I'm at range from 20ms to 150ms. Even lower numbers are possible (though rare). Anything more than that and players start getting angry at you for causing lag / throwing registration off. The players in a game may be spread all over the country, and those numbers tend to hold true for most everyone. Anything over 150ms and something's not right.

For a VPN connection to your place of work where you should be physically close enough to visit the office in person, you ought to be able to stay near the low end of that range. That said, read the tracert carefully. I work at a college, and I recently traced from home (on campus at the time!) to a campus server less than a block away. I was on a DSL line, and the college's provider is a fiber line from Time Warner. We're in rural Nebraska, and the packets hopped through Denver and then to Texas before the two providers' networks finally peered, and then routed through Chicago on the way back to town. That's quite a trip just to pull packets from less than 1/4 mile away. I switched over to a Time Warner cable line to match the college's ISP, and my tracert's got a whole lot more reasonable — it still hops to Lincoln, but it's down to 10ms on average and much of that is just moving through my 6yr old wireless router. So you might see if a friend with a different ISP can get better results.

The slowness in one direction but not the other also indicates to me that it likely has to do with your company's gateway, specifically the content filter if there is one. Those can add significant overhead (read: latency) to processing packets. It's likely your IT staff specifically bypassed the content filter for VPN traffic in one direction, but did not (or perhaps could not without rendering the filter moot) bypass the traffic in the other direction.

The most logical thing I could think of was that perhaps the destination itself (hku.hk) has some firewall and doesn't respond to traceroute requests

This is the most common cause you will see on the net. Traceroute either uses UDP or ICMP packets with a reduced TTL value so packets would expire before they get to the destination. At the routers where they expire, it might or might not be allowed to respond with TTL-exceeded messages to the originator. Additionally, ICMP might be filtered altogether somewhere along the route so the response would be generated but simply filtered before it gets back to you.

why would this fool traceroute into practically not stopping?

Because traceroute is designed not to stop unless it receives a response from the destination.

Further reading: http://en.wikipedia.org/wiki/Traceroute#Implementation