In what way is a partially encrypted webpage insecure?

Let's examine each case from the perspective of an active attacker Malroy and a passive attacker Eve.

Case 1: An insecure page loading a secure iframe to transmit confidential data

Passive: You're secure against passive attacks while you use the secure iframe. However, in the case of log-in iframes, if your session token is ever sent in the clear, Eve can impersonate you. (I still count impersonation as "passive" here, since Eve is not actively tampering with your connection; she's just making her own connections with new information she learned.)

Active: If the HTML page itself is insecure, you've already totally lost. You can have every subresource on the page be securely transmitted, but it doesn't matter: Malroy has already rewritten your page to use totally different resources.

Case 2: A secure page loading an insecure page via an iframe

Passive: Obvious major problem here: anything you do in the iframe is in plain view. However, Eve can't see what you do in the top-level secure page. Still, the user is left confused about what elements on the page can be interacted with securely and which can't.

Active: Malroy can make anything appear in the iframe; I hope you weren't using it for anything important. I don't think there's any way for Malroy to break out of the iframe and read or alter your outer secure page, because browsers already assume cross-origin iframes are not trustworthy. If there were a way to break out of the iframe, I think it would be considered a serious security bug in your browser (which isn't to say those don't exist, but that's an implementation problem, not a theoretical issue with mixed content).

Case 3: A secure page linking to insecure JS

Passive: Eve can learn what HTTPS site you are viewing, based on what HTTP resources you load. (Granted, she might be able to do this over a secure connection, based on destination IP address and size/pattern of the encrypted resources you fetch. Regardless, HTTP only makes things easier for her.)

Active: As you guessed, Malroy can make your HTTPS page completely rewrite itself by feeding it an altered script.

Case 4: A secure page linking to insecure sources like images, CSS

Passive: Same as case 3, above.

Active: CSS is pretty powerful. If Malroy could rewrite a CSS resource, he could do some pretty heavy presentation manipulation. As an example, perhaps Malroy re-styles a the inputs fields of a forum's "Create New Thread" page to look like a log-in page. This tricks the user into thinking his session has timed out, and he unwitting submits his credentials as a public new post.

An active attacker could also use CSS to prompt a client to participate in a CSRF attack, e.g., by using background-image: url(http://www.bigbank.com/transfer?amt=1000000&to=malroy).

This page has an excellent explanation and demo: http://www.troyhunt.com/2013/06/the-security-futility-that-is-embedding.html

If you assume the attacker can change the non-encrypted parts of a page, then he will be able to change them so that they include his own malicious login form, instead of the secure login form.

A possibility that pops into my mind is session high-jacking. If the session cookie for example is transfered in a non-secured manner, then this could be high-jacked.