Now, if miners stop using that code --- and nothing in the node software can force them to do that AFAIK --- what kind of trade-off are we making? What are the risks?
The thing Luke pointed out is an extremely major issue, so it'd be crazy for anyone to use this until that behavior of mining software has been changed.
If that's addressed, then something like this change would make confirmations somewhat less reliable for lightweight wallets. You'd probably want several (3-6) extra confirmations to get the same level of security as before. However, the benefit is that it might be less of a problem for blocks to propagate slowly across the network. (Currently, if blocks take too long to propagate then it can cause orphan blocks for miners, and in severe cases protracted chain forks can result.) I'm not sure exactly how much benefit headers-first would actually bring, though. I guess maybe the benefit could be large enough to safely allow for larger block sizes, but my instinct is that the maximum benefit wouldn't actually be very large. More thought and measurements would be necessary.
If this was rolled out generally, several precautions would be necessary to ensure that a whole bunch of miners don't accidentally mine many blocks on top of an invalid chain. Furthermore, there's a nightmare scenario where the majority of miners mine on an invalid chain and never stop mining on it until manually fixed. Something like headers-first mining would have to ensure that these things are impossible, or that they could cause only small, limited damage.
Headers-first seems to me like mainly an improvement over the headers-only or validationless mining that some miners seem to be doing now, but not something ideal. I think that IBLT / weak blocks will be the real eventual solution to this problem.
