I don't fully agree with that assessment. DNSSec makes it harder with offline keys, yes, but there's no reason your DNS server can't have an API that allows you to provision the TXT record (in fact, most DNS server software supports something like that, and the vast majority of people use DNS services such as CloudFlare, Dyn or Route 53 which definitely do have something like that). There's also no reason you'll have to grant your web server access to the DNS server API - you can run a separate certificate management server with no exposed ports. dns-01 is probably the most commonly used verification method for shared hosting providers, exactly because it's hard to (accidentally) break for users.
There are plugins for apache and, experimentally, nginx that do this without any downtime. Reloading the web server configuration doesn't require any downtime and is no different from reloading your certificate, which you'd have to do anyway. I'm sure someone will write a plugin for HAProxy sooner or later.
No, it just sends that "fake" hostname as the SNI value. The hostname that's being looked up is still the one you're requesting the certificate for.
Sure, but you're talking about a rather rare setup which you chose because of a number of (IMO) largely hypothetical risk factors. And you're asking the collective of Let's Encrypt's user base to bear the burden of being able to support that environment by accepting the risk that has lead to http-01 being HTTP-only (which, at the very least, seems to have convinced the ACME WG). At the same time, there are two other challenge types which could work in your environment, but would (I'll give you that 
) require more effort. I don't think it's unreasonable to ask you to bear that burden in a setup that's not all that common.