It appears to be a signed message, and for these sorts of things, I'm more of a fan of signed data (and the transport being unimportant) than a signed transport and unsigned data: there's a lot less attack surface on both ends.

apt, yum, PGP, etc. work the same way. There remains a decent argument for a secure transport anyway for privacy / avoiding side channels, or a general desire for HTTP delenda est, but it's nowhere near as strong an argument, HTTPS only provides marginal benefit to the side channels (Tor to a hidden service is much more effective), and other engineering concerns can legitimately override these concerns.

I think that may be purposeful. If your local certificate management system is on the fritz, you don't want that rejecting updates to the core cert lists. Probably better to fall back on some other cryptological system on the files themselves, since the content is not private, it's just the authenticity you care about.

I don't think it's really a big deal. Since the list is signed, an active attacker would only be able to replay an old version of the list... but it's hard to see how that would be worse than just blocking the request entirely.

Doesn't matter if it's signed.