It is probably because the appspot.com domain is in the HSTS set. It will "opportunistically" upgrade http requests to https.
Go to chrome://net-internals and query appspot.com:

static_sts_domain: appspot.com
static_upgrade_mode: OPPORTUNISTIC
static_sts_include_subdomains: true
static_sts_observed: 1493614800
static_pkp_domain: appspot.com
static_pkp_include_subdomains: true
static_pkp_observed: 1493614800
static_spki_hashes: ......

It seems be a preloaded entry and cannot be deleted via chrome://net-internals

Marking it as WAI...

Is this the long term behavior we want for interstitials? If I navigate to http://evil.com and click through the interstitial, should I always get another one if HSTS redirects to https://evil.com?

I understand seeing two interstitials if evil_a.com redirects to evil_b.com, but the http->https seems like a very confusing distinction for end users. The feature seemed totally broken to a few people who have seen this.

Technically, http://evil.com and https://evil.com can host completely different content and have different threat types, that's the main reason we don't feel comfortable skipping checking the https://evil.com simply because user clicks through http://evil.com. 

I agree, this behavior is not ideal, it might confuse some end users. Safe Browsing has a very low false positive rate. We'd rather user stays on the safe side rather than providing them with a easier click-through experience. 

Thanks for the additional clarification jialiul, I think that's the right tradeoff.