So, the quick sync you describe would be susceptible to a fake chain attack. Basically, when your node would do a quick-sync, it would select a random peer that has a proper blockheight (longest chain rule), get the latest 200 blocks, and then move forward like everything was normal. A malicious peer could instead provide a fake chain that is "valid" for 200 blocks, and here validity is a poor word, because there's no way to actually validate the last 200 blocks. You need the rest of the blockchain to check that each transaction in those 200 blocks is referencing real outputs somewhere else on the chain. So the best you could do is a check of the hash chain.
So anyhoo, you are served up this fake minichain, and you proceed to make a transaction. Your transaction now exists on the minichain but not on the real chain. What the attacker can do with this depends on how complex the attacker is, i guess. If the situation is reversed, and the attacker is sending you monero for some goods, he could send you monero on the fake chain and then receive the goods, and still have his monero on the main chain.
So the question becomes how to make sure the minichain you are using is valid. This, i think, can be addressed by using the headers-first synchronization. With this approach, you download the headers from multiple peers - so just a list of hashes of the full chain. In monero's case, we can also download the transaction hashes to increase our ability to check the validity. You can then either compare that the hash-chains from the multiple peers agree with each other, or perform a quick hash validation (because you could grab the transaction IDs, which are used in the block hash via a merkle root.. well, maybe not. This depends on whether you can reconstruct the tree).
Anyway, once you've got an agreement amongst your peers that you have the valid hash chain, you can then download the last 200 blocks and see that the downloaded blocks match the hash chain.
I did some research into this by diving into an extensive issue conversation on bitcoins github. I can't find the link right now.
Basically, this is akin to a SPV approach, where the user is trusting the hashes of other peoples blockchains.
This approach is not used in bitcoin, for instance, because it violates the security model that the core software needs to implement in order to maintain trustlnessness. (this is what I took away from the github issue discussion).
The idea with a true blockchain sync is that you do not need to trust the validation of another node. Your node creates the genesis block, and then you receive the next n blocks from some other node. Your node then performs full validation. For block 1, your node checks that the transactions in that block are valid. It then checks that the header PoW is valid. Then it moves onto the next block.
In this way, you truly re-create the blockchain using data from other nodes. You independently validate that the blockchain you have follows consensus.
By using what you are proposing (headers first, SPV style), the only attack I can think of is an isolation attack, but this is no different than a full sync IMO. Even a full-on complete validation sync is susceptible to an isolation attack.