I'm just saying that all they need is the network communication code to be able to broadcast the withdrawal transactions, and they should have redundancy in their setup in case a bug is triggered in one client or a server goes down. Also, I doubt they are using bitcoin-qt... I'm not sure where kazu got that from.
Their problem is that their wallet and their blockchain database and their network code are all in one package, so they can't generate transactions because they don't know which outputs they have to spend.
Once those three things get separated it become a lot easier. If you've still got a working blockchain database, and you are keeping track of which outputs you've spend and which you haven't, then you can generate the transaction manually and use the pushtx feature on blockchain.info to broadcast it if need be.
there is a case to be made for using bitcoind. It's tried and true, community-reviewed and in widespread use.
It's a proof of concept, the kind you need to start with in order to rapidly develop a new application, but it's architecturally unsuitable for production use. As the Bitcoin ecosystem grows up, companies will be forced to migrate to something better suited to their use case.