@mholt, can you describe a scenario where you think a cleverer client will be able to benefit from falling back to a different challenge type?
My intuitions may have been narrowed by years of trying to help people use Certbot, which would generally not be able to fall back this way (basically no Certbot authenticators can actually natively successfully complete more than one challenge type, while --preferred-challenges is basically only used with -a manual and does not actually imply that automation would be able to solve multiple different challenges¹). So I think my intuitions developed this way match up well with @aarongable's intuitions.
But I did just read a thread (and a blog post by you) where you and @bmw were talking about how, indeed, non-tightly-server-integrated clients like Certbot are not that great at automation and reliability compared to integrated ones like Caddy. Which I think most of us have agreed on for years. 
Still, I don't immediately how a more sophisticated or merely more integrated ACME client will commonly be able to benefit from falling back to a different challenge type, even given that it can potentially solve more than one (at least the ALPN challenge in addition to the HTTP challenge). Is there a likely case for that? A server firewall that blocks port 80 and not port 443, or blocks port 443 and not port 80?
¹ Edit: well, there is an experimental Certbot plugin written by @_az that does a super-magic thing with Linux networking to intercept challenge requests before they even reach the web server, and I suggested that as an April Fool's joke this could be proposed to implement TLS-ALPN-01 too, which @Osiris seemed to think would be genuinely worthwhile and doable. If certbot-standalone-nfq did implement both HTTP-01 and TLS-ALPN-01 then I guess it would be a novel example of a Certbot authenticator that could natively and automatically solve both of these challenges without additional user scripting.