It should just label HTTP pages as "not secure", full stop. Because they aren't secure. Or at least, any page with a form. Never mind if it's a password field or not.
So right now it would be counterproductive to mark all http pages as "not secure". But it's the long-term goal.
The user will then forever ignore it (because they like that web site) and the whole exercise is wasted.
Of course relying on a provider that might cancel the free plan at any time is not ideal, but worst case you just have to revert your DNS and it's done.
They even have multiple modes, the "Flexible" one works even with no changes at your server at all. It obviously makes the CF<->server transfer insecure, but your users would still get a "green lock", if that's what you're after.
This is from their in-settings help: https://www.cloudflare.com/a/static/images/ssl/ssl.png
And then how does the renew process work?
It would freak a significant proportion of the community out who fail to distinguish what is a web page and what is their computer. They would honestly think that their computer is not secure and their local files/photos would be at risk. After the initial panic and speaking to their "friend who is good with computers" that they will just ignore it forever.
The far better approach is to aggressively warn at users at the point where they are trying to do something secure over an insecure connection. Personally I would be adding UI elements next to HTML forms saying "Do not enter your password here".
This is extremely different for most users that don't use password managers and/or unique passwords per site. As if your password is leaked. Maybe all your other sites are now leaked(with same pass) . The same can't be said of cookies.
From a naive perspective, all requests passing private information are protected in such a scenario. But, of course, since the www. subdomain is uncovered, it can be MITMed and replaced with a phishing site. (A.K.A. a "spear-phishing" attack.)
This change somewhat fixes that scenario: the developer can no longer keep the /login route on the insecure www. subdomain; they'll have to serve that page securely (either by making www. secure, or, more likely—because it's lazier—just moving /login to the app. subdomain.)
Even though www. can still be MITMed to replace it with a phishing subdomain, that subdomain can no longer serve a login form itself. It would have to link to a "real" phishing FQDN (one the attacker controls enough to get a TLS cert for), at which point that domain can just be found and blacklisted by the browser vendors.
In a sense, it forces the attacker into the open, where the attacker themselves can be caught/blocked, rather than simply their attack being caught/blocked. (In other words, it forces MITM attackers into a situation more akin to current botnet malware-writers, where they must put up C&C infrastructure which can be traced back to them.)
Of course, this isn't nearly as good as just securing the www. subdomain; and it will force much more work (likely, doing said securing) on those who want to embed a login form directly on their www. subdomain's landing page. But, in the interim while we work on universalizing TLS, it will drastically decrease the value of spear-phishing attacks, just as spam filters drastically decrease the value of unsolicited bulk email ad campaigns.