Since it doesn't use the normal ways to download extension, I would assume it does not use TLS connection. Secret downloads has the problem to display certification errors and similar things to the users, so they would likely have to reimplemented quite a few code paths to make that work properly. https and tls is also not mentioned in either bug threads, which is a worrying sign.
If it uses TLS, then the bug is less exploitable but does still violate security policy of the vetting process, signed code and license classification (closed-source blob). At minimum, it leaves anyone vulnerable to arbitrary code injection from Google.
> Since it doesn't use the normal ways to download extension, I would assume it does not use TLS connection
If this was some random enterprise Java app, yes, that would be a reasonable assumption but you're talking about one of the most heavily audited codebases in existence, which has one of the best security teams in the world working on making TLS stronger and aggressively pinning certificates. Their track record would merit actually looking at the source rather than simply speculating.
It really looks like it uses the normal way to download extensions; the Web Store.
I'd be more concerned that the only thing the patch seems to do is not activate the hotword extension. It seems to still download and install it. I mean, maybe I'm wrong here. I think that checking through https://chromium.googlesource.com/chromium/src/+/f269d3b5482... for ENABLE_HOTWORDING is the right thing to do if one wants to understand the change that was made.
But this isn't a 'secret' download. Google isn't trying to hide it at all, it's just a feature for the browser. So there is no reason to try to avoid problems associated with certificate errors.
If it uses TLS, then the bug is less exploitable but does still violate security policy of the vetting process, signed code and license classification (closed-source blob). At minimum, it leaves anyone vulnerable to arbitrary code injection from Google.