This is what I'd mainly be worried about. I don't know anything about this in-depth level of Linux networking, but, like, does this only work if the incoming HTTP request is all within one packet? Maybe that's "good enough" for a lot of common scenarios, and I can see how it might help things, but it also sounds like a nightmare to try to diagnose if people get different behavior depending on the MSS/MTU/etc. that a router on the path (sometimes?) gives them, or if a CA starts putting a different user-agent or some other HTTP header in (or using HTTP 2.0 or 3.0?) and something somewhere starts treating it differently.
Sure, but messing with internals of kernel queues and spoofing packets doesn't sound like "reducing friction" to me, but I may be just an old fuddy-duddy. I guess I'm just saying that I think it's great to experiment with, but I don't know as it should be made the "default" for people to try using yet. 
It might be really neat if this could be integrated with monitoring Apache/Nginx/etc., so that this didn't reply with the packet but could just be used as diagnostics to see if the request was even getting to the web server. That might help inform if the problem is with the automatic configuration of the web server to serve the challenge (in which case the packet-spoofing option I guess might be helpful), or just the packets not getting the server (which I suspect is usually the problem people are dealing with, at least if this forum is any indication). That is, if you're trying to make things more automatic for people using certbot, you may get more mileage out of helping them check if they have IPv6 or DNSSEC misconfigured rather than worrying about their port 80 queues.