Also your tracker (tracker.bitcoinarmory.com) is a single point of failure that way, without it your users will NOT be able to find each other.
If you want a more recent bootstrap file, maybe suggest a change to https://github.com/bitcoin/bitcoin/blob/master/src/checkpoints.cpp but please at least make your torrent public, so people can find each other via DHT, LPD and PEX too.
The torrent library we found (BitTornado) is kind of old and doesn't support DHT. We setup the tracker to accommodate this, and our guy actually found a way to bridge the peer swarms using a tracker compatible with this library (assuming we're using the same torrent, which we will when new official ones are released). We had to make the appropriate design decisions: BitTornado worked flawlessly out of the box on all OS, pure-python, and stupid-easy to integrate. It was more work to change BitTornado than it was to simply do it this way.
One problem with the official one is that it's not updated regularly. Until Core 0.9.0, the checkpoints are 3 months behind, and so is the torrent. We wanted to make sure we can provide a more-frequently-updated torrent, as "topping off" the blockchain after bootstrapping appears to be a huge bottleneck. For me, using the old torrent required 2 hours of bootstrapping and 2-3 hours of "topping off". With the newer torrents, it's 2-3 hours total. We're already setting up all the peers to do it, we wanted to optimize that.
We have a variety of seedboxes setup across a dozen services to guarantee that our peer swarm is flexible and robust to any one (or 5) service providers going down. I understand the tracker thing, and it's in our plan to get a couple more, setup the same way to add extra robustness. But in the end, it's not really a single point of "failure", because Armory will fall back on regular P2P download if torrent doesn't work. Worst case is status quo.